Release 20.1 will contain a new approach to kv-level transaction locking. Instead of storing all locks inline in the MVCC keyspace and finding locks during request evaluation, locks will now be maintained in a separate lock-table. While replicated locks (intents) will not be pulled into a persistent lock-table keyspace during this release, the lock-table structure will track these locks, as well as unreplicated (best-effort) locks which enable SELECT FOR UPDATE (see #40205). Additionally, the lock-table structure will lead to significant improvements in transaction queuing. The lock-table's lock wait-queues will replace the current contentionQueue, leading to improved fairness between transactions and reduced latency now that the lock wait-queues react directly to intent resolution. For more on this change, see #41720.
The rest of this issue enumerates the remaining work items for the lock-table and storage/concurrency package that should get into this release. It does not include any work items that are specific to SELECT FOR UPDATE's use of the storage/concurrency package.
Must Have
Nice To Have
Feel free to modify. Please check off when changes merge.
Release 20.1 will contain a new approach to kv-level transaction locking. Instead of storing all locks inline in the MVCC keyspace and finding locks during request evaluation, locks will now be maintained in a separate lock-table. While replicated locks (intents) will not be pulled into a persistent lock-table keyspace during this release, the lock-table structure will track these locks, as well as unreplicated (best-effort) locks which enable SELECT FOR UPDATE (see #40205). Additionally, the lock-table structure will lead to significant improvements in transaction queuing. The lock-table's lock wait-queues will replace the current
contentionQueue, leading to improved fairness between transactions and reduced latency now that the lock wait-queues react directly to intent resolution. For more on this change, see #41720.The rest of this issue enumerates the remaining work items for the lock-table and
storage/concurrencypackage that should get into this release. It does not include any work items that are specific to SELECT FOR UPDATE's use of thestorage/concurrencypackage.Must Have
waitElsewherestate be used only for a replicated lock that is held: @sumeerbhola Locktable improvements #45040 storage/concurrency: test and bugfix for clearing the locks when the #45080kv/contention/nodes=4: @nvanbenschotenkv,sysbench, andtpccto detect regression: @nvanbenschotenNice To Have
lockTableGuardImplbetween waiting on lock holder and waiting on queued requests storage/concurrency: implement lockTableWaiter #44885acquireLockby not removing from lock holder'slockTableGuardImpl.mu.locksFeel free to modify. Please check off when changes merge.