mariadb/mysql-test/t/merge-big.test
Dmitry Lenev a6c00c276e Part of fix for bug#52044 "FLUSH TABLES WITH READ LOCK and
FLUSH TABLES <list> WITH READ LOCK are incompatible" to
be pushed as separate patch.

Replaced thread state name "Waiting for table", which was
used by threads waiting for a metadata lock or table flush, 
with a set of names which better reflect types of resources
being waited for.

Also replaced "Table lock" thread state name, which was used 
by threads waiting on thr_lock.c table level lock, with more
elaborate "Waiting for table level lock", to make it 
more consistent with other thread state names.

Updated test cases and their results according to these 
changes.

Fixed sys_vars.query_cache_wlock_invalidate_func test to not
to wait for timeout of wait_condition.inc script.
2010-08-06 15:29:37 +04:00

82 lines
3 KiB
Text

#
# Test of MERGE tables with multisession and many waits.
#
# This test takes rather long time so let us run it only in --big-test mode
--source include/big_test.inc
# We use some debug-only features in this test
--source include/have_debug.inc
# We use INFORMATION_SCHEMA.PROCESSLIST in this test
--source include/not_embedded.inc
--disable_warnings
drop table if exists t1,t2,t3,t4,t5,t6;
--enable_warnings
--echo #
--echo # Bug#26379 - Combination of FLUSH TABLE and REPAIR TABLE
--echo # corrupts a MERGE table
--echo # Problem #3
--echo #
# Two FLUSH TABLES within a LOCK TABLES segment could invalidate the lock.
# This did *not* require a MERGE table.
#
# To increase reproducibility it was necessary to enter a sleep of 2
# seconds at the end of wait_for_tables() after unlock of LOCK_open. In
# 5.0 and 5.1 the sleep must be inserted in open_and_lock_tables() after
# open_tables() instead. wait_for_tables() is not used in this case. The
# problem was that FLUSH TABLES releases LOCK_open while having unlocked
# and closed all tables. When this happened while a thread was in the
# loop in mysql_lock_tables() right after wait_for_tables()
# (open_tables()) and before retrying to lock, the thread got the lock.
# And it did not notice that the table needed a refresh after the
# [re-]open. So it executed its statement on the table.
#
# The first FLUSH TABLES kicked the INSERT out of thr_multi_lock() and
# let it wait in wait_for_tables() (open_table()). The second FLUSH
# TABLES must happen while the INSERT was on its way from
# wait_for_tables() (open_table()) to the next call of thr_multi_lock().
# This needed to be supported by a sleep to make it repeatable.
#
CREATE TABLE t1 (c1 INT) ENGINE= MyISAM;
LOCK TABLE t1 WRITE;
#SELECT NOW();
--echo # connection con1
connect (con1,localhost,root,,);
let $con1_id= `SELECT CONNECTION_ID()`;
SET SESSION debug="+d,sleep_open_and_lock_after_open";
send INSERT INTO t1 VALUES (1);
--echo # connection default
connection default;
--echo # Let INSERT go into thr_multi_lock().
#--sleep 8
#SELECT ID,STATE,INFO FROM INFORMATION_SCHEMA.PROCESSLIST;
let $wait_condition= SELECT 1 FROM INFORMATION_SCHEMA.PROCESSLIST
WHERE ID = $con1_id AND STATE = 'Waiting for table metadata lock';
--source include/wait_condition.inc
#SELECT NOW();
--echo # Kick INSERT out of thr_multi_lock().
FLUSH TABLES;
#SELECT NOW();
--echo # Let INSERT go through open_tables() where it sleeps.
#--sleep 8
#SELECT ID,STATE,INFO FROM INFORMATION_SCHEMA.PROCESSLIST;
let $wait_condition= SELECT 1 FROM INFORMATION_SCHEMA.PROCESSLIST
WHERE ID = $con1_id AND STATE = 'Waiting for table metadata lock';
--source include/wait_condition.inc
#SELECT NOW();
--echo # Unlock and close table and wait for con1 to close too.
FLUSH TABLES;
#SELECT NOW();
--echo # This should give no result.
SELECT * FROM t1;
#SELECT NOW();
UNLOCK TABLES;
--echo # connection con1
connection con1;
reap;
SET SESSION debug="-d,sleep_open_and_lock_after_open";
disconnect con1;
--echo # connection default
connection default;
DROP TABLE t1;