Open vi opened 1 year ago
previous db: 1: a 2: b
write batch sets these to: 1: x 2: y
then it is conceivable that reads concurrent to that write batch could observe either a or x for 1, or b or y for 2. but no tears. no unrelated keys are impacted. None can not be returned for reads that begin after the initial values are written.
that said, I'm hacking on a simple MVCC implementation today that might avoid this confusion completely.
Marble::read
for any key duringMarble::write_batch
would be either pre-write_batch
or post-write_batch
one, not an "out-of-thin-air" value or a "teared" value with a first half of the buffer old and second half of the buffer new?None
before switching to the post-write_batch
one?write_match
)? What worst can happen from an attempt to read an entry that is being modified?