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
-
Activity
Field | Original Value | New Value |
---|---|---|
Link |
This issue relates to |
Link |
This issue relates to |
Fix Version/s | 10.7 [ 24805 ] |
Assignee | Jan Lindström [ jplindst ] | Seppo Jaakola [ seppo ] |
Link |
This issue relates to |
Fix Version/s | 10.8 [ 26121 ] |
Fix Version/s | 10.9 [ 26905 ] |
Fix Version/s | 10.10 [ 27530 ] |