diff options
| author | sjaakola <seppo.jaakola@iki.fi> | 2020-05-25 14:23:42 +0300 |
|---|---|---|
| committer | sjaakola <seppo.jaakola@iki.fi> | 2020-05-25 19:30:23 +0300 |
| commit | 1af6e92f0b106c0588f89c51b749c573262e82d1 (patch) | |
| tree | 50d183a9a65c112799b0de89929fdbd27abb386e /sql/service_wsrep.cc | |
| parent | dc22acfdb62745017226a5c698c1bc3ee3e3563e (diff) | |
| download | mariadb-git-1af6e92f0b106c0588f89c51b749c573262e82d1.tar.gz | |
MDEV-22666 galera.MW-328A hang
The hang can happen between a lock connection issuing KILL CONNECTION for a victim,
which is in committing phase.
There happens two resource deadlockwhere killer is holding victim's
LOCK_thd_data and requires trx mutex for the victim.
The victim, otoh, holds his own trx mutex, but requires LOCK_thd_data
in wsrep_commit_ordered(). Hence a classic two thread deadlock happens.
The fix in this commit changes innodb commit so that wsrep_commit_ordered()
is not called while holding trx mutex. With this, wsrep patch commit time mutex
locking does not violate the locking protocol of KILL command
(i.e. LOCK_thd_data -> trx mutex)
Also, a new test case has been added in galera.galera_bf_kill.test for scenario
where a client connection is killed in committting phase.
Diffstat (limited to 'sql/service_wsrep.cc')
| -rw-r--r-- | sql/service_wsrep.cc | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/sql/service_wsrep.cc b/sql/service_wsrep.cc index 7cac2bf741b..ada0bde803f 100644 --- a/sql/service_wsrep.cc +++ b/sql/service_wsrep.cc @@ -299,6 +299,7 @@ extern "C" void wsrep_commit_ordered(THD *thd) thd->wsrep_trx().state() == wsrep::transaction::s_committing && !wsrep_commit_will_write_binlog(thd)) { + DEBUG_SYNC(thd, "before_wsrep_ordered_commit"); thd->wsrep_cs().ordered_commit(); } } |