Currently we abort if we try to read a tuple whose write lock is held by another transaction. This is too conservative. We can read the tuple if the txn holding the write lock has a timestamp greater than the reader's timestamp, since no matter what the writer does (commit or abort), that version of the committed tuple is the version that reader will see.
This also adds an optimization that if the current read timestamp of the tuple is greater than or equal to the transaction attempting to read, immediately succeed. There's no reason to try to take the latch to update the read timestamp to a smaller value.
Coverage decreased (-0.004%) to 76.507% when pulling 8c20445f0fb9daeda3fa5ad562e640afded0e75b on mbutrovich:mvto into 3bc6d461dcd10e8f5b8dd6bdcdb0dbfe23d0256e on cmu-db:master.
Currently we abort if we try to read a tuple whose write lock is held by another transaction. This is too conservative. We can read the tuple if the txn holding the write lock has a timestamp greater than the reader's timestamp, since no matter what the writer does (commit or abort), that version of the committed tuple is the version that reader will see.
This also adds an optimization that if the current read timestamp of the tuple is greater than or equal to the transaction attempting to read, immediately succeed. There's no reason to try to take the latch to update the read timestamp to a smaller value.