-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce RESET request #435
Conversation
I am unsure about this remark in the SQLite docs:
I think we do want to keep the database in WAL mode after the reset, but it's unclear to me how the server can implement "touching" the schema in this way without knowing what tables (if any) are present in the DB. |
Codecov Report
@@ Coverage Diff @@
## master #435 +/- ##
===========================================
- Coverage 73.47% 60.32% -13.16%
===========================================
Files 31 31
Lines 4679 4771 +92
Branches 1462 1413 -49
===========================================
- Hits 3438 2878 -560
- Misses 745 1022 +277
- Partials 496 871 +375
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Ah, it looks like SQLITE_DBCONFIG_RESET_DATABASE was added in SQLite v3.24.0, which is not available on Bionic. We could do some |
+1 |
I'm not entirely sure why this requirement is there, but maybe you can use |
I would maybe check it at runtime too, with |
rv = sqlite3_db_config(l->conn, SQLITE_DBCONFIG_RESET_DATABASE, 1, 0); | ||
assert(rv == 0); | ||
exec->status = sqlite3_exec(l->conn, "VACUUM", NULL, NULL, NULL); | ||
rv = sqlite3_db_config(l->conn, SQLITE_DBCONFIG_RESET_DATABASE, 0, 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, does dqlite's memory footprint shrink after resetting a DB? If it's not shrinking, we should look into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that would be a good thing to measure. Let me see if I can add some basic tracing of memory consumption before and after the VACUUM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I don't see any change in number of DB pages, number of WAL frames, or number of shm regions after leaderApplyFrames returns vs. before VACUUM
. @freeekanayaka, can you think of anything that would be preventing our VFS from dropping allocated memory when SQLite is done using it? (I could also just be looking in the wrong places -- I don't fully understand the VFS subsystem yet.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the VACUUM
actually succeed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it does -- I just tried adding an extra tracef to confirm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I don't see any change in number of DB pages, number of WAL frames, or number of shm regions after leaderApplyFrames returns vs. before
VACUUM
. @freeekanayaka, can you think of anything that would be preventing our VFS from dropping allocated memory when SQLite is done using it? (I could also just be looking in the wrong places -- I don't fully understand the VFS subsystem yet.)
Not on the top of my head, but I also don't have a clear picture of the changes that are being made. The SQLite memory allocator has some helper functions to track the amount of allocated memory, perhaps that could be useful to check.
Latest push:
|
Signed-off-by: Cole Miller <cole.miller@canonical.com>
8dc07ed
to
6946015
Compare
Okay, we should first figure out why the database is not shrinking before merging this. Maybe it waits until a checkpoint command, not sure. |
This implementation of RESET doesn't work when I rebase on top of #440. That's expected, since one of the first things done in the implementation of VACUUM is to ATTACH an additional temporary database to the given connection. I don't think we should merge this unless and until we can support ATTACH DATABASE properly. |
Closing in favor of an issue |
This PR implements a new RESET request that allows a dqlite client to restore the database it has opened to a pristine state. Instead of deleting the in-memory database "file", we use the SQLITE_DBCONFIG_RESET_DATABASE method described here, which goes through the normal VFS channels. This still requires a separate request because of the out-of-band sqlite3_db_config calls. The implementation of the new request mimics what would happen if we did
EXEC_SQL("VACUUM")
, with some simplifications since we don't need to run a barrier or bind parameters.Closes #422
Signed-off-by: Cole Miller cole.miller@canonical.com