KILL QUERY:
find_thread_by_id(thd->LOCK_thd_data , thd->LOCK_thd_kill) => thd->awake_no_mutex() => innobase_kill_query() => lock_trx_handle_wait( lock_sys->mutex, trx->mutex if not wsrep victim)
From these only lock_sys->mutex is global mutex. All others are either thread internal (thd) or transaction internal (trx). Therefore, mutex deadlock is possible if and only if thread we have selected as victim for BF abort and thread user is trying to kill are exactly the same one. While BF abort also will call thd->awake() it will have trx->lock.was_chosen_as_wsrep_victim=true and then we do not take lock_sys->mutex or trx->mutex at lock_trx_handle_wait(). Second problem is possible when in wsrep_kill_one_trx() we set trx->lock.was_chosen_as_wsrep_victim=true and release thd->LOCK_thd_data mutex. Now if we have a schedule where KILL is executed there is possibility that we either try to take lock_sys->mutex and have to wait or if this is same thread as victim no InnoDB mutexes are taken. Furthermore, in bf_abort() we might take thd->LOCK_thd_data again in wsrep-lib.
In this fix candidate we release lock_sys->mutex and trx->mutex before
we call wsrep_innobase_kill_one_trx(). Thus, it is safe to take
thd->LOCK_thd_data similarly as KILL does. We can remove
was_chosen_as_wsrep_victim variable from trx as it is not anymore
needed.
MDEV-22465: DROP indexed COLUMN is wrongly claimed to be ALGORITHM=INSTANT
ha_innobase::check_if_supported_inplace_alter(): Do not allow
ALGORITHM=INSTANT for operations that avoid a table rebuild
but involve dropping (or creating) secondary indexes.
