Since LWT’s get an isolated view the DB, what would the resulting value be in the following scenario:
- Row A col=1
- LWT begins with
Update A set col=2 if col=1
- LWT fails before completing, currently only a paxos read would see this value, not a normal read
- A normal write occurs and does
updated A set col=3
- A paxos read sees the partial update and completes it while reading
Will that paxos read see col=2 or col=3? Technically the LWT finished later, but it was based on an old isolated view of the DB.
My assumption is that it would see col=3 because even though the LWT would have been applied, there has been a new value since it started and thus it won’t apply the LWT.
It depends on the timing of the failure, unfortunately. If the paxos round is finished, it just failed to apply to the base table, the apply will use the original round timestamp. So a (supposedly later) timestamp of step 4 will prevail and the result will be “3”.
If, however, the Paxos write fails at accept phase, the SELECT with Storng Consistency, which sees the unfinished accept round, will finish it with a refreshed ballot, so the result is going to be 2.
You can see this for yourself in storage_proxy.cc, begin_and_repair_paxos, search for replicas_missing_most_recent_commit, and observe the used mutation timestamp, and then compare with refreshed_in_progress and accept_proposal