Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sql: add per-statement retry loop for read committed transactions #100145

Closed
nvanbenschoten opened this issue Mar 30, 2023 · 0 comments · Fixed by #107044
Closed

sql: add per-statement retry loop for read committed transactions #100145

nvanbenschoten opened this issue Mar 30, 2023 · 0 comments · Fixed by #107044
Assignees
Labels
A-read-committed Related to the introduction of Read Committed A-sql-executor SQL txn logic C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)

Comments

@nvanbenschoten
Copy link
Member

nvanbenschoten commented Mar 30, 2023

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

@nvanbenschoten nvanbenschoten added C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) A-sql-executor SQL txn logic T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions) A-read-committed Related to the introduction of Read Committed labels Mar 30, 2023
craig bot pushed a commit that referenced this issue Aug 16, 2023
108728: build: add basic infrastructure for remote execution with EngFlow r=rail a=rickystewart

Add the `--config engflow` which sets some appropriate configurations
for building against our engflow cluster, and set some other metadata.
Also bump some test sizes and shard counts to get everything working.

Epic: [CRDB-8308](https://cockroachlabs.atlassian.net/browse/CRDB-8308)
Release note: None

108817: sql: simplifiy tracking of injected txn retry errors r=rafiss a=rafiss

Rather than using the txn epoch, we can just track how many errors were
injected. This lets us have a bit more control over how many errors to
inject, without having to rely on how the KV layer handles different
types of transaction retries.

informs: #100145
split off from: #107044
Release note: None

Co-authored-by: Ricky Stewart <[email protected]>
Co-authored-by: Rafi Shamim <[email protected]>
@craig craig bot closed this as completed in 0333b78 Aug 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-read-committed Related to the introduction of Read Committed A-sql-executor SQL txn logic C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants