Background

All operations performed by a transaction in CRDB have an associated sequence number, which are used to provide relative ordering for all operations. Savepoints are built on top of this concept -- whenever a savepoint is rolled back, associated sequence numbers are considered to be "ignored".

As of the time of writing, CRDB deviates from lock rollback compared to Postgres -- savepoint rollback does not result in lock rollbacks. This is because the client never issues an RPC to update any locks acquired under savepoints. However, the OnLockUpdate method on the LockManager, and the concurrency_control package in general, is designed to handle lock rollbacks.

Propopsal

Locks in the lock table store all sequence numbers at which they have been acquired. Calls to OnLockUpdate are passed a list of IgnoredSequenceNumbers. These are then used to prune the list of sequence numbers (holder.seqs) the lock is held at; if this list becomes empty, the lock is no longer held, and removed from the lock table.

In addition to the OnLockUpdate path, we should do this pruning on the lock (re-)acquisition path as well. This would entail teaching the arguments of OnLockAcquired (roachpb.LockAcquisition) to have access to a list of IgnoredSequenceNumbers. We could then make use of this list like we do in OnLockUpdate.

Jira issue: CRDB-27375