Skip to content

kv: implement SHARED lock strength for unreplicated locks  #91545

@arulajmani

Description

@arulajmani

The lockTable currently only supports the exclusive lock strength, but was designed to support varying degrees of lock strengths. Specifically, it was designed to support both SHARED and UPGRADE (tracked separately in #49684) locking strength as well.

// +-----------+-----------+-----------+-----------+-----------+
// | | None | Shared | Upgrade | Exclusive |
// +-----------+-----------+-----------+-----------+-----------+
// | None | | | | X^† |
// +-----------+-----------+-----------+-----------+-----------+
// | Shared | | | X | X |
// +-----------+-----------+-----------+-----------+-----------+
// | Upgrade | | X | X | X |
// +-----------+-----------+-----------+-----------+-----------+
// | Exclusive | X^† | X | X | X |
// +-----------+-----------+-----------+-----------+-----------+

Additional context

Today SQL accepts syntax of the form SELECT ... FOR SHARE but does not lock any of the rows returned. It should be easy enough to correctly use the SHARED locking strength once the lockTable supports it.

Jira issue: CRDB-21312

Epic CRDB-26544

Metadata

Metadata

Assignees

Labels

A-kv-transactionsRelating to MVCC and the transactional model.A-read-committedRelated to the introduction of Read CommittedC-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)P-1Issues/test failures with a fix SLA of 1 monthT-kvKV Team

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions