Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Won't Do
-
None
Description
There following issues here:
- Whenever Galera BF (brute force) transaction decides to abort conflicting transaction it will kill that thread using thd::awake()
- Whenever replication selects a thread as a victim it will call thd::awake()
- User KILL [QUERY|CONNECTION] ... for a thread it will also call thd::awake()
Whenever one of these actions is executed we will hold number of InnoDB internal mutexes and thd mutexes.
Sometimes these mutexes are taken in different order causing mutex deadlock (see one detailed case below).
Refs
Attachments
Issue Links
- blocks
-
MDEV-12009 Allow to force kill user threads/query which are flagged as high priority by Galera
- Closed
- relates to
-
MDEV-17063 server locks up and is killed after innodb_fatal_semaphore_wait_threshold is reached
- Closed
-
MDEV-19803 Long semaphore wait error on galera.MW-388
- Closed
-
MDEV-23328 Server hang due to Galera lock conflict resolution
- Closed
-
MDEV-18874 Galera test MW-286 causes Mutex = TTASEventMutex<GenericPolicy>]: Assertion `!is_owned()' failed. assertion
- Closed
-
MDEV-21910 KIlling thread on Galera could cause mutex deadlock
- Closed
-
MDEV-23851 Galera assertion at lock0lock.cc line 655 because of BF-BF lock wait
- Closed