concurrency: implement latching changes to support SHARED locks #102264
Assignees
Labels
A-kv-transactions
Relating to MVCC and the transactional model.
A-read-committed
Related to the introduction of Read Committed
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
T-kv
KV Team
Comments
arulajmani
added
C-bug
arulajmani
added a commit
to arulajmani/cockroach
that referenced
this issue
Aug 28, 2023
Reads that acquire shared locks need to be isolated with concurrent write requests. They also need to be isolated with exclusive-locking reads. They can, however, run concurrently with other shared locking reads and non-locking reads. As described in the shared locks RFC, to make these semantics work, shared-locking reads should acquire read latches at `hlc.MaxTimestamp`. This patch makes that change and adds test cases for all these interactions. Closes cockroachdb#102264 Release note: None
craig bot
pushed a commit
that referenced
this issue
Aug 29, 2023
109633: kv: latching changes to support shared locks r=nvanbenschoten a=arulajmani Reads that acquire shared locks need to be isolated with concurrent write requests. They also need to be isolated with exclusive-locking reads. They can, however, run concurrently with other shared locking reads and non-locking reads. As described in the shared locks RFC, to make these semantics work, shared-locking reads should acquire read latches at `hlc.MaxTimestamp`. This patch makes that change and adds test cases for all these interactions. Closes #102264 Release note: None Co-authored-by: Arul Ajmani <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the problem
Currently, non-locking read requests acquire read latches at their read timestamp. This isolates them from concurrent writers at equal or lower timestamps. However, this permits write requests at higher timestamps to proceed, as they do not conflict with such non-locking reads.
The expectation with Shared locks is that they should protect the read at higher timestamps as well. This makes the current read latch semantics inadequate. As proposed in the Shared locks RFC, shared lock requests should acquire read latches at max timestamp instead of the requests's timestamp. This ensures they don't conflict with concurrent reads (reads that acquire shared locks or non-locking reads) but do conflict with all concurrent writes.
Jira issue: CRDB-27371
The text was updated successfully, but these errors were encountered: