Fix for bug #56251 "Deadlock with INSERT DELAYED and MERGE

tables".

Attempting to issue an INSERT DELAYED statement for a MERGE
table might have caused a deadlock if it happened as part of
a transaction or under LOCK TABLES, and there was a concurrent
DDL or LOCK TABLES ... WRITE statement which tried to lock one
of its underlying tables.

The problem occurred when a delayed insert handler thread tried
to open a MERGE table and discovered that to do this it had also
to open all underlying tables and hence acquire metadata
locks on them. Since metadata locks on the underlying tables were
not pre-acquired by the connection thread executing INSERT DELAYED,
attempts to do so might lead to waiting. In this case the
connection thread had to wait for the delayed insert thread.
If the thread which was preventing the lock on the underlying table
from being acquired had to wait for the connection thread (due to
this or other metadata locks), a deadlock occurred. 
This deadlock was not detected by the MDL deadlock detector since 
waiting for the handler thread by the connection thread is not
represented in the wait-for graph.

This patch solves the problem by ensuring that the delayed
insert handler thread never tries to open underlying tables 
of a MERGE table. Instead open_tables() is aborted right after
the parent table is opened and a ER_DELAYED_NOT_SUPPORTED 
error is emitted (which is passed to the connection thread and
ultimately to the user).

0 files changed, 0 insertions, 0 deletions