• Vlad Lesin's avatar
    MDEV-29081 trx_t::lock.was_chosen_as_deadlock_victim race in lock_wait_end() · 8ff10969
    Vlad Lesin authored
    The issue is that trx_t::lock.was_chosen_as_deadlock_victim can be reset
    before the transaction check it and set trx_t::error_state.
    
    The fix is to reset trx_t::lock.was_chosen_as_deadlock_victim only in
    trx_t::commit_in_memory(), which is invoked on full rollback. There is
    also no need to have separate bit in
    trx_t::lock.was_chosen_as_deadlock_victim to flag transaction it was
    chosen as a victim of Galera conflict resolution, the same variable can be
    used for both cases except debug build. For debug build we need to
    distinguish deadlock and Galera's abort victims for debug checks. Also
    there is no need to check for deadlock in lock_table_enqueue_waiting() for
    Galera as the coresponding check presents in lock_wait().
    
    Local variable "error_state" in lock_wait() was replaced with
    trx->error_state, because before the replace
    lock_sys_t::cancel<false>(trx, lock) and lock_sys.deadlock_check() could
    change trx->error_state, which then could be overwritten with the local
    "error_state" variable value.
    
    The lock_wait_suspend_thread_enter DEBUG_SYNC point name is misleading,
    because lock_wait_suspend_thread was eliminated in e71e6133. It was renamed
    to lock_wait_start.
    
    Reviewed by: Marko Mäkelä, Jan Lindström.
    8ff10969
cursor-restore-locking.result 1.34 KB