Closed hx235 closed 3 weeks ago
@hx235 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.
@hx235 has updated the pull request. You must reimport the pull request before landing.
@hx235 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.
@hx235 has updated the pull request. You must reimport the pull request before landing.
@hx235 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.
LGTM, thanks for the fix! Do you need this for
TestCheckpoint
?
Good question - the checkpoint compares the checkpoint db with expected state instead of actual DB query result. So it won't be affected by un-flushed WAL ....
@hx235 merged this pull request in facebook/rocksdb@a2f772910ed80a3ba357351bf5e835bb73f4fd6d.
Context/Summary: When manual WAL flush is used, the following can happen:
t1: Issued Put(k1) to original DB. It entered WAL buffer since manual_wal_flush_one_in > 0. It never made it to WAL file without FlushWAL() t2: The same WAL got back-up and restored to restore DB. So the restore DB's WAL does not contain this Put() t3: The same WAL in the original DB got FlushWAL() so it got the Put() entry
Querying k1 in original and restored DB will give different result and fail our consistency check in stress test.
This PR fixed it.
Test:
Repro-ed quickly before the fix and stably run after the fix.