cockroachdb / cockroachdb/cockroach
kvserver: ensure unreplicated locks aren't lost on replicated acquire
- Dominant language
- Go
- Stars
- 32.5k
- Forks
- 4.1k
- PR merge metrics
- PR metrics pending
Description
Currently, when a unreplicated lock is reacquired as a replicated lock at an equal or higher strength, we drop the
unreplicated lock from the in-memory lock table.
We believe this is an important optimisation.
Unfortunately, it can result in the loss of a lock in the face of rollback savepoints. Concretely,
- Unreplicated lock acquired @ seq 1
- Replicated lock acquired @ seq 2
- Rolback seq 2
Can result in the lock@seq=1 being "lost". The lock will no longer be in the in-memory lock table. The lock at seq 2 will still be on disk, but I believe this lock too can be lost in the event of a ResolveIntent request that has observed the txn record with the updated IgnoredSeqNumbers array.
One potential solution here is for lock acquisition requests to additionally carry known savepoint sequence number ranges. That is, sequence points that could possibly be rolled back with a `ROLLBACK TO`. This information could then be used to keep the unreplicated lock at seq1 only when it was required for rollback correctness.
Jira issue: CRDB-47800
Contributor guide
Assessment
This issue has not been assessed yet.