mirror of
https://github.com/facebook/rocksdb.git
synced 2024-11-27 11:43:49 +00:00
f5e44f3490
Summary: This PR fix a possible manual flush hanging scenario because of its expectation that others will clear out excessive memtables was not met. The root cause is the FlushRequest rescheduling logic is using a stricter criteria for what a write stall is about to happen means than `WaitUntilFlushWouldNotStallWrites` does. Currently, the former thinks a write stall is about to happen when the last memtable is half full, and it will instead reschedule queued FlushRequest and not actually proceed with the flush. While the latter thinks if we already start to use the last memtable, we should wait until some other background flush jobs clear out some memtables before proceed this manual flush. If we make them use the same criteria, we can guarantee that at any time when`WaitUntilFlushWouldNotStallWrites` is waiting, it's not because the rescheduling logic is holding it back. Pull Request resolved: https://github.com/facebook/rocksdb/pull/12771 Test Plan: Added unit test Reviewed By: ajkr Differential Revision: D58603746 Pulled By: jowlyzhang fbshipit-source-id: 9fa1c87c0175d47a40f584dfb1b497baa576755b |
||
---|---|---|
.. | ||
compacted_db_impl.cc | ||
compacted_db_impl.h | ||
db_impl.cc | ||
db_impl.h | ||
db_impl_compaction_flush.cc | ||
db_impl_debug.cc | ||
db_impl_experimental.cc | ||
db_impl_files.cc | ||
db_impl_follower.cc | ||
db_impl_follower.h | ||
db_impl_open.cc | ||
db_impl_readonly.cc | ||
db_impl_readonly.h | ||
db_impl_secondary.cc | ||
db_impl_secondary.h | ||
db_impl_write.cc |