Commit a27d85aa authored by Vasil Dimov's avatar Vasil Dimov

Fix the non-determinism in innodb_information_schema.test

Thanks to Kristian Nielsen for finding out the root cause for the
failure, see: https://bugs.launchpad.net/maria/+bug/677407
parent 61449541
...@@ -116,11 +116,29 @@ SELECT * FROM ```t'\"_str` WHERE c1 = '4' FOR UPDATE; ...@@ -116,11 +116,29 @@ SELECT * FROM ```t'\"_str` WHERE c1 = '4' FOR UPDATE;
# executes before some of them, resulting in less than expected number # executes before some of them, resulting in less than expected number
# of rows being selected from innodb_locks. If there is a bug and there # of rows being selected from innodb_locks. If there is a bug and there
# are no 14 rows in innodb_locks then this test will fail with timeout. # are no 14 rows in innodb_locks then this test will fail with timeout.
let $count = 14; # Notice that if we query INNODB_LOCKS more often than once per 0.1 sec
let $table = INFORMATION_SCHEMA.INNODB_LOCKS; # then its contents will never change because the cache from which it is
-- source include/wait_until_rows_count.inc # filled is updated only if it has not been read for 0.1 seconds. See
# the above enables the query log, re-disable it # CACHE_MIN_IDLE_TIME_US in trx/trx0i_s.c.
-- disable_query_log let $cnt=10;
while ($cnt)
{
let $success=`SELECT COUNT(*) = 14 FROM INFORMATION_SCHEMA.INNODB_LOCKS`;
if ($success)
{
let $cnt=0;
}
if (!$success)
{
real_sleep 0.2;
dec $cnt;
}
}
if (!$success)
{
-- echo Timeout waiting for rows in INNODB_LOCKS to appear
}
SELECT lock_mode, lock_type, lock_table, lock_index, lock_rec, lock_data SELECT lock_mode, lock_type, lock_table, lock_index, lock_rec, lock_data
FROM INFORMATION_SCHEMA.INNODB_LOCKS ORDER BY lock_data; FROM INFORMATION_SCHEMA.INNODB_LOCKS ORDER BY lock_data;
......
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