1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-24 19:42:23 +03:00

MDEV-13472 rpl.rpl_semi_sync_wait_point crashes because of thd_destructor_proxy

The thd_destructor_proxy detects that no transactions are active and
starts srv_shutdown_bg_undo_sources(), but fails to take into account
that new transactions can still start, especially be slave but also
by other threads. In addition there is no mutex when checking for
active transaction so this is not safe.

We relax the failing InnoDB debug assertion by allowing the execution
of user transactions after the purge thread has been shut down.

FIXME: If innodb_fast_shutdown=0, we should somehow guarantee that no
new transactions can start after thd_destructor_proxy observed that
trx_sys_any_active_transactions() did not hold.
This commit is contained in:
Marko Mäkelä
2017-08-08 19:54:12 +03:00
parent ffa3789495
commit c720e68f53

View File

@ -293,14 +293,16 @@ trx_purge_add_update_undo_to_history(
After the purge thread has been given permission to exit,
in fast shutdown, we may roll back transactions (trx->undo_no==0)
in THD::cleanup() invoked from unlink_thd(). */
in THD::cleanup() invoked from unlink_thd(), and we may also
continue to execute user transactions. */
ut_ad(srv_undo_sources
|| ((srv_startup_is_before_trx_rollback_phase
|| trx_rollback_or_clean_is_active)
&& purge_sys->state == PURGE_STATE_INIT)
|| (srv_force_recovery >= SRV_FORCE_NO_BACKGROUND
&& purge_sys->state == PURGE_STATE_DISABLED)
|| (trx->undo_no == 0 && srv_fast_shutdown));
|| ((trx->undo_no == 0 || trx->in_mysql_trx_list)
&& srv_fast_shutdown));
/* Add the log as the first in the history list */
flst_add_first(rseg_header + TRX_RSEG_HISTORY,