a657ee9a9c
Summary: Consider the following WAL with 4 batch entries prefixed with their sequence at time of memtable insert. [1: BEGIN_PREPARE, PUT, PUT, PUT, PUT, END_PREPARE(a)] [1: BEGIN_PREPARE, PUT, PUT, PUT, PUT, END_PREPARE(b)] [4: COMMIT(a)] [7: COMMIT(b)] The first two batches do not consume any sequence numbers so are both prefixed with seq=1. For 2pc commit, memtable insertion takes place before COMMIT batch is written to WAL. We can see that sequence number consumption takes place between WAL entries giving us the seemingly sparse sequence prefix for WAL entries. This is a valid WAL. Because with 2PC markers one WriteBatch points to another batch containing its inserts a writebatch can consume more or less sequence numbers than the number of sequence consuming entries that it contains. We can see that, given the entries in the WAL, 6 sequence ids were consumed. Yet on recovery the maximum sequence consumed would be 7 + 3 (the number of sequence numbers consumed by COMMIT(b)) So, now upon recovery we must track the actual consumption of sequence numbers. In the provided scenario there will be no sequence gaps, but it is possible to produce a sequence gap. This should not be a problem though. correct? Test Plan: provided test. Reviewers: sdong Subscribers: andrewkr, leveldb, dhruba, hermanlee4 Differential Revision: https://reviews.facebook.net/D57645 |
||
---|---|---|
.. | ||
optimistic_transaction_db_impl.cc | ||
optimistic_transaction_db_impl.h | ||
optimistic_transaction_impl.cc | ||
optimistic_transaction_impl.h | ||
optimistic_transaction_test.cc | ||
transaction_base.cc | ||
transaction_base.h | ||
transaction_db_impl.cc | ||
transaction_db_impl.h | ||
transaction_db_mutex_impl.cc | ||
transaction_db_mutex_impl.h | ||
transaction_impl.cc | ||
transaction_impl.h | ||
transaction_lock_mgr.cc | ||
transaction_lock_mgr.h | ||
transaction_test.cc | ||
transaction_util.cc | ||
transaction_util.h |