Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11
Description
This came up while I was reviewing MDEV-29081. It is possible that also older versions than 10.6 are affected by this, but I did not check it.
If Galera invokes ha_abort_transaction() (from wsrep_abort_thd() or wsrep_handle_mdl_conflict()), it will set a flag to have an InnoDB transaction in another thread to be aborted and rolled back.
If no InnoDB conflicts occur, lock_wait() will not be executed and the chosen victim may neglect the request for a long time.
I see that ha_innobase::write_row(), ha_innobase::update_row(), ha_innobase::delete_row() are already doing something extra if trx_t::is_wsrep() holds. I think that those functions need to check the Galera asynchronous kill status.
Attachments
Issue Links
- relates to
-
MDEV-29293 MariaDB stuck on starting commit state (waiting on commit order critical section)
- Closed
-
MDEV-29860 Simplify transaction rollback initiation on termination from the other thread
- Closed
-
MDEV-29081 trx_t::lock.was_chosen_as_deadlock_victim race in lock_wait_end()
- Closed