cockroachdb / cockroachdb/cockroach

kvserver: ensure unreplicated locks aren't lost on replicated acquire

Open
#141,360 2 comments 0 reactions 0 assignees View on GitHub
A-buffered-writes A-kv-transactions C-enhancement
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.