-
Notifications
You must be signed in to change notification settings - Fork 4.1k
sql: acquire replicated locks on explicit SELECT FOR UPDATE #100194
Copy link
Copy link
Closed
Labels
A-read-committedRelated to the introduction of Read CommittedRelated to the introduction of Read CommittedA-sql-optimizerSQL logical planning and optimizations.SQL logical planning and optimizations.C-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)P-1Issues/test failures with a fix SLA of 1 monthIssues/test failures with a fix SLA of 1 monthT-sql-queriesSQL Queries TeamSQL Queries Team
Description
Once we implement replicated key-level locks (#100193), we should then switch explicit SELECT FOR {SHARE/UPDATE} over to acquire locks with a Replicated durability.
Implicit uses of SELECT FOR UPDATE as part of mutation statements can continue to acquire cheaper, best-effort unreplicated locks.
Jira issue: CRDB-26582
Epic CRDB-25322
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
A-read-committedRelated to the introduction of Read CommittedRelated to the introduction of Read CommittedA-sql-optimizerSQL logical planning and optimizations.SQL logical planning and optimizations.C-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)P-1Issues/test failures with a fix SLA of 1 monthIssues/test failures with a fix SLA of 1 monthT-sql-queriesSQL Queries TeamSQL Queries Team
Type
Projects
Status
Done