MDEV-10962 Deadlock with 3 concurrent DELETEs by unique keybb-10.6-midenok-MDEV-10962

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.

0 files changed, 0 insertions, 0 deletions