Bug #54332 Deadlock with two connections doing LOCK TABLE+INSERT DELAYED
The problem was that deadlocks involving INSERT DELAYED were not detected. The reason for this is that two threads are involved in INSERT DELAYED: the connection thread and the handler thread. The connection thread would wait while the handler thread acquired locks and opened the table. In essence, this adds an edge to the wait-for-graph between the connection thread and the handler thread that the deadlock detector is unaware of. Therefore many deadlocks involving INSERT DELAYED were not detected. This patch fixes the problem by having the connection thread acquire the metadata lock the table before starting the handler thread. This allows the deadlock detector to detect any possible deadlocks resulting from trying to acquire a metadata lock the table. If a metadata lock is successfully acquired, the handler thread is started and given a copy of the ticket representing the metadata lock. When the handler thread then tries to lock and open the table, it will find that it already has the metadata lock and therefore not acquire any new metadata locks. Test cases added to delayed.test.
Showing
Please register or sign in to comment