summaryrefslogtreecommitdiff
path: root/mysql-test/suite/innodb/t/deadlock_wait_lock_race.test
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-29869 mtr failure: innodb.deadlock_wait_thr_raceVlad Lesin2022-10-261-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. The merge aeccbbd926e759a5c3b9818d9948a35918404478 has overwritten lock0lock.cc, and the changes of MDEV-29622 and MDEV-29635 were partially lost, this commit restores the changes. 2. innodb.deadlock_wait_thr_race test: The following hang was found during testing. There is deadlock_report_before_lock_releasing sync point in Deadlock::report(), which is waiting for sel_cont signal under lock_sys_t lock. The signal must be issued after "UPDATE t SET b = 100" rollback, and that rollback is executing undo record, which is blocked on dict_sys latch request. dict_sys is locked by the thread of statistics update(dict_stats_save()), and during that update lock_sys lock is requested, and can't be acquired as Deadlock::report() holds it. We have to disable statistics update to make the test stable. But even if statistics update is disabled, and transaction with consistent snapshot is started at the very beginning of the test to prevent purging, the purge can still be invoked for system tables, and it tries to open system table by id, what causes dict_sys.freeze() call and dict_sys latching. What, in combination with lock_sys::xx_lock() causes the same deadlock as described above. We need to disable purging globally for the test as well. All the above is applicable to innodb.deadlock_wait_lock_race test also.
* MDEV-29635 race on trx->lock.wait_lock in deadlock resolutionVlad Lesin2022-10-211-0/+62
Returning DB_SUCCESS unconditionally if !trx->lock.wait_lock in lock_trx_handle_wait() is wrong. Because even if trx->lock.was_chosen_as_deadlock_victim was not set before the first check in lock_trx_handle_wait(), it can be set after the check, and trx->lock.wait_lock can be reset by another thread from lock_reset_lock_and_trx_wait() if the transaction was chosen as deadlock victim. In this case lock_trx_handle_wait() will return DB_SUCCESS even the transaction was marked as deadlock victim, and continue execution instead of rolling back. The fix is to check trx->lock.was_chosen_as_deadlock_victim once more if trx->lock.wait_lock is reset, as trx->lock.wait_lock can be reset only after trx->lock.was_chosen_as_deadlock_victim was set if the transaction was chosen as deadlock victim.