Bug#26379 - Combination of FLUSH TABLE and REPAIR TABLE

            corrupts a MERGE table

Post-pushbuild fix for a Valgrind warning.

mysql-test/r/merge.result

@@ -1875,10 +1875,6 @@ CHECK TABLE t1 EXTENDED;
 Table	Op	Msg_type	Msg_text
 test.t1	check	status	OK
 LOCK TABLES t2 WRITE, t1 WRITE;
-SELECT * FROM t2;
-c1
-1
-LOCK TABLES t2 WRITE, t1 WRITE;
 REPAIR TABLE t1;
 Table	Op	Msg_type	Msg_text
 test.t1	repair	status	OK

mysql-test/t/merge.test

@@ -1279,8 +1279,6 @@ CHECK TABLE t1 EXTENDED;
 #
 # Not using FLUSH TABLES before REPAIR.
 LOCK TABLES t2 WRITE, t1 WRITE;
-SELECT * FROM t2;
-LOCK TABLES t2 WRITE, t1 WRITE;
 REPAIR TABLE t1;
 CHECK TABLE t1;
 REPAIR TABLE t1;

sql/sql_trigger.cc

@@ -489,8 +489,11 @@ bool mysql_create_or_drop_trigger(THD *thd, TABLE_LIST *tables, bool create)
   /* Under LOCK TABLES we must reopen the table to activate the trigger. */
   if (!result && thd->locked_tables)
   {
-    close_data_files_and_morph_locks(thd, table->s->db.str,
-                                     table->s->table_name.str);
+    /*
+      Must not use table->s->db.str or table->s->table_name.str here.
+      The strings are used in a loop even after the share may be freed.
+    */
+    close_data_files_and_morph_locks(thd, tables->db, tables->table_name);
     thd->in_lock_tables= 1;
     result= reopen_tables(thd, 1, 0);
     thd->in_lock_tables= 0;