diff options
author | sjaakola <seppo.jaakola@iki.fi> | 2018-04-24 10:26:34 +0300 |
---|---|---|
committer | sjaakola <seppo.jaakola@iki.fi> | 2018-04-24 16:57:39 +0300 |
commit | 2f0b8f3e027840dab1fd6322e35ecd0f3d7edc08 (patch) | |
tree | 69aae3bc2639e60cee09da5a91dddcafac830a93 /sql/wsrep_applier.cc | |
parent | 82d4f081861b227e35299f4ea2e24f55b7146fd1 (diff) | |
download | mariadb-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.cc | 8 |
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); |