Currently, a cooperative lease transfer discards the entire lock table on the outgoing leaseholder and rebuilds the lock table on the incoming leaseholder lazily. This means that any unreplicated lock on the outgoing leaseholder will be lost. This causes the best-effort mutual exclusion provided by unreplicated locks (those acquired using implicit or explicit SELECT ... FOR UPDATE) to be less reliable. This can in turn lead to transaction retries and other surprising behavior.

To avoid this, we could ship the unreplicated locks from the outgoing leaseholder to the incoming leaseholder through the lease transfer Raft proposal. This would be similar to #60521, where we started including more information in the handoff between leaseholders during cooperative lease changes.

If we make this change, we will also want to consider the corresponding situations with range splits and merges.

EDIT: in #100193, we added support for replicated locks. Instead of shipping unreplicated locks between leaseholders using a new mechanism, it probably makes sense to instead flush unreplicated locks to the replicated state machine (push them through raft) ahead of performing a lease transfer, a split, or a merge.

Jira issue: CRDB-12681

Epic CRDB-23101