Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
104362: kv: establish new read snapshot on statement/batch boundaries under RC r=nvanbenschoten a=nvanbenschoten Closes #100133. This commit teaches Read Committed transactions to establish a new external "read snapshot" on each SQL statement or KV batch boundary. The per-statement/batch read snapshot logic is integrated into the transaction `Stepping` infrastructure in an analogous manner to how the transaction's internal `readSeq` is advanced. For transactions with stepping enabled (e.g. SQL transactions), the `Step` API now advances the transaction's external read snapshot (i.e. `ReadTimestamp`) to a timestamp captured from the local HLC clock. This ensures that subsequent read-only operations observe the writes of other transactions that were committed before the time the statement began. For transactions with stepping disabled (e.g. raw KV transactions), each batch implicitly advances the read snapshot. This ensures that the batch observes the writes of other transactions that were committed before the batch was issued. This read snapshot will be at least as recent as the previous read snapshot, and will typically be more recent (i.e. it will never regress). Consistency with prior reads in the transaction is not maintained, so reads of previously read keys may not be "repeatable" and may observe "phantoms". On the other hand, by not maintaining consistency between read snapshots, isolation-related retries (write-write conflicts) and consistency-related retries (uncertainty errors) have a higher chance of being refreshed away (client-side or server-side) without the need for client intervention (i.e. without requiring a statement-level retry). This benefit can be seen in `TestTxnCoordSenderRetries`. As described in the Read Committed RFC, the transaction's uncertainty interval is not reset when establishing a new read snapshot. See section "Read Uncertainty Intervals" of the RFC for the rationale behind this decision. Release note: None Co-authored-by: Nathan VanBenschoten <[email protected]>
- Loading branch information