The server crashes with:
2023-12-28 17:29:32 89 [Note] WSREP: ::rollback() thread: 89, client_state exec client_mode high priority trans_state aborted killed 0
|
2023-12-28 17:29:32 76 [Note] WSREP: MDL conflict·
|
schema: test
|
request: (75 seqno 626 wsrep (toi, exec, aborted) cmd 3 8 TRUNCATE TABLE t1)
|
granted: (89 seqno -1 wsrep (high priority, exec, aborting) cmd 0 161 (null))
|
2023-12-28 17:29:32 76 [Note] WSREP: MDL ticket: type: MDL_SHARED_WRITE space: TABLE db: test name: t1 (Waiting for table metadata lock)
|
2023-12-28 17:29:32 76 [Note] WSREP: MDL BF-BF conflict
|
schema: test
|
request: (75 seqno 626 wsrep (toi, exec, aborted) cmd 3 8 TRUNCATE TABLE t1)
|
granted: (89 seqno -1 wsrep (high priority, exec, aborted) cmd 0 161 (null))
|
2023-12-28 17:29:32 76 [Note] WSREP: MDL ticket: type: MDL_SHARED_WRITE space: TABLE db: test name: t1 (Waiting for table metadata lock)
|
2023-12-28 17:29:32 76 [ERROR] Aborting
|
The problem is as following:
Applied SR transaction gets BF-aborted, but there is a time window when it's already rolled back and its wsrep transaction's state is set to aborted, but it has not released MDL locks yet. This situation is incorrectly determined during MDL conflict handling and the server aborts thinking there are two high-priority transactions (TOI and high-prio applied) conflicting, which should never happen.
Major MDEV-32160 GCF-1060 test failure due to wsrep MDL conflict
