From 5918b17004674f425f2cd1d4f0bac29b3bcecb35 Mon Sep 17 00:00:00 2001 From: seppo Date: Tue, 24 Mar 2020 11:01:42 +0200 Subject: MDEV-21473 conflicts with async slave BF aborting (#1475) If async slave thread (slave SQL handler), becomes a BF victim, it may occasionally happen that rollbacker thread is used to carry out the rollback instead of the async slave thread. This can happen, if async slave thread has flagged "idle" state when BF thread tries to figure out how to kill the victim. The issue was possible to test by using a galera cluster as slave for external master, and issuing high load of conflicting writes through async replication and directly against galera cluster nodes. However, a deterministic mtr test for the "conflict window" has not yet been worked on. The fix, in this patch makes sure that async slave thread state is never set to IDLE. This prevents the rollbacker thread to intervene. The wsrep_query_state change was refactored to happen by dedicated function to make controlling the idle state change in one place. --- sql/sql_connect.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'sql/sql_connect.cc') diff --git a/sql/sql_connect.cc b/sql/sql_connect.cc index 3491796ba85..b2900a20b28 100644 --- a/sql/sql_connect.cc +++ b/sql/sql_connect.cc @@ -1342,7 +1342,7 @@ void do_handle_one_connection(CONNECT *connect) if (WSREP(thd)) { mysql_mutex_lock(&thd->LOCK_thd_data); - thd->wsrep_query_state= QUERY_EXITING; + wsrep_thd_set_query_state(thd, QUERY_EXITING); mysql_mutex_unlock(&thd->LOCK_thd_data); } #endif -- cgit v1.2.1