• Aleksey Midenkov's avatar
    MDEV-10962 Deadlock with 3 concurrent DELETEs by unique key · b2f099b4
    Aleksey Midenkov authored
    Deadlock on concurrent acquisition of multiple types is fixed by
    prioritization over waiting locks if transaction already has
    non-waiting lock on same (block, heap_no).
    
    Deadlock happens by this scheme:
    
    1. TXA acquires L1 (index "a", X|NOT_GAP);
    2. TXB waits L2 (index "a", X|NOT_GAP) for L1;
    3. TXA waits L3 (index "a", X) for L2.
    
    TXB waits TXA, TXA waits TXB: DeadlockChecker wants a victim.
    
    Since L3 is weaker than L1 we can not apply optimization from
    MDEV-18706. But the problem of this loop is silly queuing. TXA already
    acquired non-gap lock L1 and wants to expand it into next-key. TXB from
    parallel thread does the same. Deadlock detection processes the
    requests in FIFO order so the above order fails. But if L3 is acquired
    before L2 there is no deadlock.
    
    We can make queue smarter: if there are already lock seized on same
    resource (block, heap_no), no matter what type it is, we priritize all
    further locks on that transaction. There is no treat to fair
    scheduling as this is basically lock promotion in 2PL scheme.
    b2f099b4
xa.test 8.41 KB