summaryrefslogtreecommitdiff
path: root/sql/wsrep_applier.cc
diff options
context:
space:
mode:
authorsjaakola <seppo.jaakola@iki.fi>2018-04-24 10:26:34 +0300
committersjaakola <seppo.jaakola@iki.fi>2018-04-24 16:57:39 +0300
commit2f0b8f3e027840dab1fd6322e35ecd0f3d7edc08 (patch)
tree69aae3bc2639e60cee09da5a91dddcafac830a93 /sql/wsrep_applier.cc
parent82d4f081861b227e35299f4ea2e24f55b7146fd1 (diff)
downloadmariadb-git-2f0b8f3e027840dab1fd6322e35ecd0f3d7edc08.tar.gz
MDEV-16005 sporadic failures with galera tests MW-328B and MW-328C
These test can sporadically show mutex deadlock warnings between LOCK_wsrep_thd and LOCK_thd_data mutexes. This means that these mutexes can be locked in opposite order by different threads, and thus result in deadlock situation. To fix such issue, the locking policy of these mutexes should be revised and enforced to be uniform. However, a quick code review shows that the number of lock/unlock operations for these mutexes combined is between 100-200, and all these mutex invocations should be checked/fixed. On the other hand, it turns out that LOCK_wsrep_thd is used for protecting access to wsrep variables of THD (wsrep_conflict_state, wsrep_query_state), whereas LOCK_thd_data protects query, db and mysys_var variables in THD. Extending LOCK_thd_data to protect also wsrep variables looks like a viable solution, as there should not be a use case where separate threads need simultaneous access to wsrep variables and THD data variables. In this commit LOCK_wsrep_thd mutex is refactored to be replaced by LOCK_thd_data. By bluntly replacing LOCK_wsrep_thd by LOCK_thd_data, will result in double locking of LOCK_thd_data, and some adjustements have been performed to fix such situations.
Diffstat (limited to 'sql/wsrep_applier.cc')
-rw-r--r--sql/wsrep_applier.cc8
1 files changed, 4 insertions, 4 deletions
diff --git a/sql/wsrep_applier.cc b/sql/wsrep_applier.cc
index e5c95780df5..723804c76db 100644
--- a/sql/wsrep_applier.cc
+++ b/sql/wsrep_applier.cc
@@ -98,11 +98,11 @@ static wsrep_cb_status_t wsrep_apply_events(THD* thd,
DBUG_RETURN(WSREP_CB_FAILURE);
}
- mysql_mutex_lock(&thd->LOCK_wsrep_thd);
+ mysql_mutex_lock(&thd->LOCK_thd_data);
thd->wsrep_query_state= QUERY_EXEC;
if (thd->wsrep_conflict_state!= REPLAYING)
thd->wsrep_conflict_state= NO_CONFLICT;
- mysql_mutex_unlock(&thd->LOCK_wsrep_thd);
+ mysql_mutex_unlock(&thd->LOCK_thd_data);
if (!buf_len) WSREP_DEBUG("empty rbr buffer to apply: %lld",
(long long) wsrep_thd_trx_seqno(thd));
@@ -197,9 +197,9 @@ static wsrep_cb_status_t wsrep_apply_events(THD* thd,
}
error:
- mysql_mutex_lock(&thd->LOCK_wsrep_thd);
+ mysql_mutex_lock(&thd->LOCK_thd_data);
thd->wsrep_query_state= QUERY_IDLE;
- mysql_mutex_unlock(&thd->LOCK_wsrep_thd);
+ mysql_mutex_unlock(&thd->LOCK_thd_data);
assert(thd->wsrep_exec_mode== REPL_RECV);