CockroachDB's planned implementation of read committed isolation will use a per-statement read snapshot. A key property of this isolation level is that it can provide per-statement consistency without client-side intervention (e.g. retry errors are not returned to the client) through the use of a gateway-side per-statement retry loop. The use of a per-statement read snapshot means that the retry loop can catch isolation (WriteTooOld) and consistency (ReadWithinUncertainty) retry errors and retry just the current statement using a new read snapshot.

We'll need to build out this retry loop, likely with the use of internal transaction savepoints.

We'll also want to add a configurable retry limit for cases where per-statement consistency is getting starved on write-write conflicts.

For the case of implicit transactions (possibly only ones that are a single statement), it might be more expedient to simply use the existing retry logic, rather than adding overhead with savepoints.

Open questions:

• Should we unify the PrepareForPartialRetry API with the corresponding savepoint rollback?

Jira issue: CRDB-26568

Epic CRDB-26546