Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11
-
None
-
Can result in unexpected behaviour
Description
Local sessions having wsrep_on = OFF configuration and which conflict with applier executions may or may not be BF aborted depending on where the conflict happens:
- with MDL lock conflicts, the local session will be BF aborted
- with innodb lock conflict, the local session will not be aborted
This split behavior is probably due to regression introduced by fix for MDEV-34836: (TOI on parent table must BF abort SR in progress on a child), (commit 231900e5bb15e5d6d90b8a6daf38a0b21d1a19e7)
..having a new function for checking BF abortability:
static bool wsrep_will_BF_abort(const lock_t *lock, const trx_t *trx) |
{
|
ut_ad(wsrep_thd_is_BF(trx->mysql_thd, false)); |
|
|
/* Don't BF abort system transactions. */ |
if (!lock->trx->is_wsrep()) |
return false; |
...
|
Here, lock->trx->is_wsrep() returns 0 for local session with wsrep_on=OFF, and this avoids BF aborting. The comment says that only system threads were supposed to have immunity, but now also non wsrep local sessions got immunity as well.
Attachments
Issue Links
- is caused by
-
MDEV-34836 TOI (ALTER) hangs on a parent table if SR transaction is in progress on a child table
-
- Closed
-