Bug #51391 Deadlock involving events during rqg_info_schema test

This was a deadlock between CREATE/ALTER/DROP EVENT and a query
accessing both the mysql.event table and I_S.GLOBAL_VARIABLES.

The root of the problem was that the LOCK_event_metadata mutex was
used to both protect the "event_scheduler" global system variable
and the internal event data structures used by CREATE/ALTER/DROP EVENT.

The deadlock would occur if CREATE/ALTER/DROP EVENT held
LOCK_event_metadata while trying to open the mysql.event table,
at the same time as the query had mysql.event open, trying to
lock LOCK_event_metadata to access "event_scheduler".

This bug was fixed in the scope of Bug#51160 by using only
LOCK_global_system_variables to protect "event_scheduler".
This makes it so that the query above won't lock LOCK_event_metadata,
thereby preventing this deadlock from occuring.

This patch contains no code changes.
Test case added to lock_sync.test.

1 files changed, 20 insertions, 0 deletions

diff --git a/mysql-test/r/lock_sync.result b/mysql-test/r/lock_sync.result
index 49ef3bb1b37..18f3f6bc1a7 100644
--- a/mysql-test/r/lock_sync.result
+++ b/mysql-test/r/lock_sync.result
@@ -92,3 +92,23 @@ COMMIT;
 # Connection default
 # Reaping ALTER TABLE t1 ADD COLUMN j INT
 DROP TABLE t1, t2;
+#
+# Bug#51391 Deadlock involving events during rqg_info_schema test
+#
+CREATE EVENT e1 ON SCHEDULE EVERY 5 HOUR DO SELECT 1;
+CREATE EVENT e2 ON SCHEDULE EVERY 5 HOUR DO SELECT 2;
+# Connection con1
+SET DEBUG_SYNC="before_lock_tables_takes_lock SIGNAL drop WAIT_FOR query";
+# Sending:
+DROP EVENT e1;;
+# Connection default
+SET DEBUG_SYNC="now WAIT_FOR drop";
+SELECT name FROM mysql.event, INFORMATION_SCHEMA.GLOBAL_VARIABLES
+WHERE definer = VARIABLE_VALUE;
+name
+SET DEBUG_SYNC="now SIGNAL query";
+# Connection con1
+# Reaping: DROP EVENT t1
+# Connection default
+DROP EVENT e2;
+SET DEBUG_SYNC="RESET";