Bug#26379 - Combination of FLUSH TABLE and REPAIR TABLE

corrupts a MERGE table

Post-pushbuild fix for a Valgrind warning.
This commit is contained in:
istruewing@stella.local 2007-11-18 20:28:37 +01:00
parent 0605274155
commit b6831e182b
3 changed files with 5 additions and 8 deletions

View File

@ -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

View File

@ -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;

View File

@ -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;