Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
Description
InnoDB data dictionary cache is protected by both dict_sys.latch (an RW-lock) and dict_sys.mutex. One reason for the redundant synchronization primitive would be eliminated by MDEV-24167: the rw-lock should not be slower than a mutex.
Another reason for keeping a separate mutex is that sometimes, the mutex provides a mechanism to ‘upgrade’ the rw-lock. The most prominent case of that would be removed by MDEV-23484, if we could guarantee that transaction rollback is always protected by MDL. Currently, the rollback of recovered transactions is not being protected by MDL.
Attachments
Issue Links
- blocks
-
MDEV-25919 InnoDB reports misleading lock wait timeout on DDL operations
-
- Closed
-
- causes
-
MDEV-26551 InnoDB crash on multiple concurrent SHOW TABLE STATUS
-
- Closed
-
- is blocked by
-
MDEV-23484 Rollback unnecessarily acquires dict_operation_lock for every row
-
- Closed
-
-
MDEV-24167 InnoDB unnecessarily uses complex rw-lock implementation
-
- Closed
-
- relates to
-
MDEV-16260 Scale the purge effort according to the workload
-
- Open
-
-
MDEV-26356 Performance regression after dict_sys.mutex removal
-
- Closed
-
-
MDEV-26636 Race conditions due to attempted updates of InnoDB defragmentation statistics for temporary tables
-
- Closed
-
-
MDEV-28289 fts_optimize_sync_table() is acquiring dict_sys.latch while holding it
-
- Closed
-
-
MDEV-28462 AddressSanitizer: use-after-poison dict_index_t::get_n_nullable(unsigned long) const
-
- Closed
-
-
MDEV-29846 deadlock on dict_sys.mutex on database drop
-
- Open
-
-
MDEV-31759 Large grain of dict_sys lock by table creation affects performance
-
- Closed
-
MDEV-24258.patch
applies to a development branch of
MDEV-24167. Many tests would hang. In every case that I checked, the reason was that transaction rollback would attempt to acquire an exclusive latch while already holding it in shared mode. That would be fixed byMDEV-23484.