mirror of
https://github.com/facebook/rocksdb.git
synced 2024-11-26 16:30:56 +00:00
9b53f14a35
Summary: Pull Request resolved: https://github.com/facebook/rocksdb/pull/9060 RocksDB bottommost level compaction may zero out an internal key's sequence if the key's sequence is in the earliest_snapshot. In write-prepared transaction, checking the visibility of a certain sequence in a specific released snapshot may return a "snapshot released" result. Therefore, it is possible, after a certain sequence of events, a PUT has its sequence zeroed out, but a subsequent SingleDelete of the same key will still be output with its original sequence. This violates the ascending order of keys and leads to incorrect result. The solution is to use an extra variable `last_key_seq_zeroed_` to track the information about visibility in earliest snapshot. With this variable, we can know for sure that a SingleDelete is in the earliest snapshot even if the said snapshot is released during compaction before processing the SD. Reviewed By: ltamasi Differential Revision: D31813016 fbshipit-source-id: d8cff59d6f34e0bdf282614034aaea99be9174e1 |
||
---|---|---|
.. | ||
lock | ||
optimistic_transaction.cc | ||
optimistic_transaction.h | ||
optimistic_transaction_db_impl.cc | ||
optimistic_transaction_db_impl.h | ||
optimistic_transaction_test.cc | ||
pessimistic_transaction.cc | ||
pessimistic_transaction.h | ||
pessimistic_transaction_db.cc | ||
pessimistic_transaction_db.h | ||
snapshot_checker.cc | ||
transaction_base.cc | ||
transaction_base.h | ||
transaction_db_mutex_impl.cc | ||
transaction_db_mutex_impl.h | ||
transaction_test.cc | ||
transaction_test.h | ||
transaction_util.cc | ||
transaction_util.h | ||
write_prepared_transaction_test.cc | ||
write_prepared_txn.cc | ||
write_prepared_txn.h | ||
write_prepared_txn_db.cc | ||
write_prepared_txn_db.h | ||
write_unprepared_transaction_test.cc | ||
write_unprepared_txn.cc | ||
write_unprepared_txn.h | ||
write_unprepared_txn_db.cc | ||
write_unprepared_txn_db.h |