Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
12.3.2
-
Related to performance
-
Improved lock granularity in lock_move_reorganize_page()
-
Q3/2026 Server Maintenance
Description
lock_move_reorganize_page() only touches record locks belonging to a single page, all of which live in one lock_sys.rec_hash cell. It nonetheless write-latches the global lock_sys.latch via LockMutexGuard, blocking every concurrent lock_sys.rd_lock() acquirer (e.g. lock_rec_lock(), lock_table()) server-wide for the whole reorganize (in case locks are present).
commit 983df00 downgrades LockMutexGuard to LockGuard (shared lock_sys.latch + exclusive latch on the page's cell). An exclusive cell latch is sufficient: it protects the cell's lock chain, the lock bitmaps, and lock->type_mode (including LOCK_WAIT). The per-iteration trx->mutex that already guards lock_rec_add_to_queue() continues to protect each trx's trx_locks list and lock_heap.
Attachments
Issue Links
- relates to
-
MDEV-40408 btr_page_reorganize_low() uses the buffer pool just to obtain a scratch block
-
- Stalled
-
-
MDEV-40427 lock_move_reorganize_page() early exit check is useful only with lock elision
-
- Closed
-
-
MDEV-20612 Improve InnoDB lock_sys scalability
-
- Closed
-
-
PERF-475 Loading...