feat: Expose wait_for_compact #841
Conversation
zaidoon1
force-pushed
the
zaidoon/expose-wait-for-compact
branch
2 times, most recently
from
d1b82d6
to
e3b78c6
Compare
src/db_options.rs
Outdated
| /// comments in DB::Close() for details. | ||
| /// | ||
| /// Default: false | ||
| pub fn set_close_db(&mut self, v: bool) { |
There was a problem hiding this comment.
I think this method shouldn't be exposed, or alternatively should be marked unsafe? It allows the underlying database to be closed without dropping the DB object, and RocksDB is pretty light on guarantees about continuing to use a DB after it was closed.
Regardless of the return status, the DB must be freed.
From the wiki:
Q: Is it safe to close RocksDB while another thread is issuing read, write or manual compaction requests?
A: No. The users of RocksDB need to make sure all functions have finished before they close RocksDB. You can speed up the waiting by calling CancelAllBackgroundWork().
Looking at the implementation, there is a closed_ flag in RocksDB but it is only checked in Close and in the destructor
There was a problem hiding this comment.
Another safe alternative would be remove this and add a pub fn wait_for_compact_and_close(self, opts: &WaitForCompactOptions) -> Result<(), Error> method that consumes the DB instance
There was a problem hiding this comment.
hmmm, ok for the time being, I'm going to remove set_close_db as I don't need it. We can revisit if someone needs this option
zaidoon1
force-pushed
the
zaidoon/expose-wait-for-compact
branch
from
10850d4
to
6d7fe89
Compare
No description provided.