Commit 81956f43 authored by Georgi Kodinov's avatar Georgi Kodinov

Bug #42419: test suite fix

Moved the test case for the bug into a separate file (and restored the 
original innodb_mysql test setup).
Used the new wait_show_condition test macro to avoid the usage of sleep

mysql-test/include/wait_show_condition.inc:
  Bug #42419: new test macro to wait for a row in SHOW to have a certain value.
mysql-test/r/innodb_bug42419.result:
  Bug #42419: test case
mysql-test/r/innodb_mysql.result:
  Bug #42419: revert to the original innodb_mysql test
mysql-test/t/innodb_bug42419.test:
  Bug #42419: test case
mysql-test/t/innodb_mysql-master.opt:
  Bug #42419: revert to the original innodb_mysql test
mysql-test/t/innodb_mysql.test:
  Bug #42419: revert to the original innodb_mysql test
parent 5e19d075
# include/wait_show_condition.inc
#
# SUMMARY
#
# Waits until the show statement ($show_statement) has at least within one of
# the rows of the result set for the field ($field) a value which fulfils
# a condition ($condition), or the operation times out.
#
#
# USAGE
#
# let $show_statement= SHOW PROCESSLIST;
# let $field= State;
# let $condition= = 'Updating';
# --source include/wait_show_condition.inc
#
# OR
#
# let $wait_timeout= 60; # Override default of 30 seconds with 60.
# let $show_statement= SHOW PROCESSLIST;
# let $field= State;
# let $condition= = 'Updating';
# --source include/wait_show_condition.inc
#
# Please do not use this use routine if you can replace the SHOW statement
# with a select. In such a case include/wait_condition.inc is recommended.
#
# Created: 2009-02-18 mleich
#
let $max_run_time= 30;
if ($wait_timeout)
{
let $max_run_time= $wait_timeout;
}
# Reset $wait_timeout so that its value won't be used on subsequent
# calls, and default will be used instead.
let $wait_timeout= 0;
# The smallest timespan till UNIX_TIMESTAMP() gets incremented is ~0 seconds.
# We add one second to avoid the case that somebody measures timespans on a
# real clock with fractions of seconds, detects that n seconds are sufficient,
# assigns n to this routine and suffers because he sometimes gets n - 1
# seconds in reality.
inc $max_run_time;
let $found= 0;
let $max_end_time= `SELECT UNIX_TIMESTAMP() + $max_run_time`;
while (`SELECT UNIX_TIMESTAMP() <= $max_end_time AND $found = 0`)
{
# Sleep a bit to avoid too heavy load.
real_sleep 0.2;
let $rowno= 1;
let $process_result= 1;
while (`SELECT $process_result = 1 AND $found = 0`)
{
let $field_value= query_get_value($show_statement, $field, $rowno);
if (`SELECT '$field_value' $condition`)
{
let $found= 1;
}
if (`SELECT '$field_value' = 'No such row'`)
{
# We are behind the last row of the result set.
let $process_result= 0;
}
inc $rowno;
}
}
if (!$found)
{
echo # Timeout in include/wait_show_condition.inc for $wait_condition;
echo # show_statement : $show_statement;
echo # field : $field;
echo # condition : $condition;
echo # max_run_time : $max_run_time;
}
CREATE TABLE t1 (a INT AUTO_INCREMENT PRIMARY KEY, b INT) ENGINE = InnoDB;
INSERT INTO t1 VALUES (1,1),(2,2),(3,3);
COMMIT;
SET AUTOCOMMIT = 0;
CREATE TEMPORARY TABLE t1_tmp ( b INT );
INSERT INTO t1_tmp (b) SELECT b FROM t1 WHERE a = 3;
INSERT INTO t1_tmp (b) SELECT b FROM t1 WHERE a = 2;
SET AUTOCOMMIT = 0;
CREATE TEMPORARY TABLE t2_tmp ( a int, new_a int );
INSERT INTO t2_tmp VALUES (1,51),(2,52),(3,53);
UPDATE t1 SET a = (SELECT new_a FROM t2_tmp WHERE t2_tmp.a = t1.a) WHERE a = 1;
UPDATE t1 SET a = (SELECT new_a FROM t2_tmp WHERE t2_tmp.a = t1.a) WHERE a = 2;
INSERT INTO t1_tmp (b) SELECT b FROM t1 WHERE a = 1;
ERROR 40001: Deadlock found when trying to get lock; try restarting transaction
Reap the server message for connection user2 UPDATE t1 ...
UPDATE t1 SET a = (SELECT new_a FROM t2_tmp WHERE t2_tmp.a = t1.a) WHERE a = 3;
DROP TABLE t1;
......@@ -1267,20 +1267,4 @@ CREATE INDEX i1 on t1 (a(3));
SELECT * FROM t1 WHERE a = 'abcde';
a
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, b INT)
ENGINE=InnoDB;
INSERT INTO t1 VALUES (1,1),(2,2),(3,3);
SET AUTOCOMMIT = 0;
CREATE TEMPORARY TABLE t1_tmp (b INT);
INSERT INTO t1_tmp SELECT b FROM t1 WHERE a = 3;
INSERT INTO t1_tmp SELECT b FROM t1 WHERE a = 2;
SET AUTOCOMMIT = 0;
CREATE TEMPORARY TABLE t2_tmp ( a INT, new_a INT);
INSERT INTO t2_tmp VALUES (1,51),(2,52),(3,53);
UPDATE t1 SET a = (SELECT new_a FROM t2_tmp WHERE t2_tmp.a = t1.a) WHERE a = 1;
UPDATE t1 SET a = (SELECT new_a FROM t2_tmp WHERE t2_tmp.a = t1.a) WHERE a = 2;
INSERT INTO t1_tmp SELECT b FROM t1 WHERE a = 1;
ERROR 40001: Deadlock found when trying to get lock; try restarting transaction
UPDATE t1 SET a = (SELECT new_a FROM t2_tmp WHERE t2_tmp.a = t1.a) WHERE a = 3;
DROP TABLE t1;
End of 5.0 tests
#
# Testcase for InnoDB
# Bug#42419 Server crash with "Pure virtual method called" on two concurrent connections
#
--source include/have_innodb.inc
let $innodb_lock_wait_timeout= query_get_value(SHOW VARIABLES LIKE 'innodb_lock_wait_timeout%', Value, 1);
if (`SELECT $innodb_lock_wait_timeout < 10`)
{
--echo # innodb_lock_wait_timeout must be >= 10 seconds
--echo # so that this test can work all time fine on an overloaded testing box
SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';
exit;
}
# Save the initial number of concurrent sessions
--source include/count_sessions.inc
# First session
connection default;
--enable_warnings
CREATE TABLE t1 (a INT AUTO_INCREMENT PRIMARY KEY, b INT) ENGINE = InnoDB;
INSERT INTO t1 VALUES (1,1),(2,2),(3,3);
COMMIT;
SET AUTOCOMMIT = 0;
CREATE TEMPORARY TABLE t1_tmp ( b INT );
INSERT INTO t1_tmp (b) SELECT b FROM t1 WHERE a = 3;
INSERT INTO t1_tmp (b) SELECT b FROM t1 WHERE a = 2;
# Second session
connect (user2,localhost,root,,,$MASTER_MYPORT,$MASTER_MYSOCK);
SET AUTOCOMMIT = 0;
CREATE TEMPORARY TABLE t2_tmp ( a int, new_a int );
INSERT INTO t2_tmp VALUES (1,51),(2,52),(3,53);
UPDATE t1 SET a = (SELECT new_a FROM t2_tmp WHERE t2_tmp.a = t1.a) WHERE a = 1;
send
UPDATE t1 SET a = (SELECT new_a FROM t2_tmp WHERE t2_tmp.a = t1.a) WHERE a = 2;
# The last update will wait for a lock held by the first session
# First session
connection default;
# Poll till the UPDATE of the second session waits for lock
let $show_statement= SHOW PROCESSLIST;
let $field= State;
let $condition= = 'Updating';
--source include/wait_show_condition.inc
# If the testing box is overloadeded and innodb_lock_wait_timeout is too small
# we might get here ER_LOCK_WAIT_TIMEOUT.
--error ER_LOCK_DEADLOCK
INSERT INTO t1_tmp (b) SELECT b FROM t1 WHERE a = 1;
# Second session
connection user2;
--echo Reap the server message for connection user2 UPDATE t1 ...
reap;
# The server crashed when executing this UPDATE or the succeeding SQL command.
UPDATE t1 SET a = (SELECT new_a FROM t2_tmp WHERE t2_tmp.a = t1.a) WHERE a = 3;
connection default;
disconnect user2;
DROP TABLE t1;
# Wait till all disconnects are completed
--source include/wait_until_count_sessions.inc
--innodb-lock-wait-timeout=3
--innodb-lock-wait-timeout=2
......@@ -1025,55 +1025,4 @@ CREATE INDEX i1 on t1 (a(3));
SELECT * FROM t1 WHERE a = 'abcde';
DROP TABLE t1;
#
# Bug #42419: Server crash with "Pure virtual method called" on two
# concurrent connections
#
connect (c1, localhost, root,,);
connect (c2, localhost, root,,);
CREATE TABLE t1 (a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, b INT)
ENGINE=InnoDB;
INSERT INTO t1 VALUES (1,1),(2,2),(3,3);
connection c1;
SET AUTOCOMMIT = 0;
CREATE TEMPORARY TABLE t1_tmp (b INT);
INSERT INTO t1_tmp SELECT b FROM t1 WHERE a = 3;
INSERT INTO t1_tmp SELECT b FROM t1 WHERE a = 2;
connection c2;
SET AUTOCOMMIT = 0;
CREATE TEMPORARY TABLE t2_tmp ( a INT, new_a INT);
INSERT INTO t2_tmp VALUES (1,51),(2,52),(3,53);
UPDATE t1 SET a = (SELECT new_a FROM t2_tmp WHERE t2_tmp.a = t1.a) WHERE a = 1;
--send
UPDATE t1 SET a = (SELECT new_a FROM t2_tmp WHERE t2_tmp.a = t1.a) WHERE a = 2;
--sleep 3
connection c1;
--error ER_LOCK_DEADLOCK
INSERT INTO t1_tmp SELECT b FROM t1 WHERE a = 1;
connection c2;
--reap
UPDATE t1 SET a = (SELECT new_a FROM t2_tmp WHERE t2_tmp.a = t1.a) WHERE a = 3;
connection default;
disconnect c1;
disconnect c2;
DROP TABLE t1;
--echo End of 5.0 tests
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment