5.5-merge

mysql-test/suite/innodb/t/innodb-timeout.test

@@ -1,5 +1,5 @@
 
-let $timeout=`select @@innodb_lock_wait_timeout`;
+let $initial_timeout=`select @@innodb_lock_wait_timeout`;
 set global innodb_lock_wait_timeout=42;
 
 connect (a,localhost,root,,);
@@ -11,19 +11,24 @@ set innodb_lock_wait_timeout=1;
 select @@innodb_lock_wait_timeout;
 
 connection b;
+let $connection_b_id=`SELECT CONNECTION_ID()`;
 select @@innodb_lock_wait_timeout;
 set global innodb_lock_wait_timeout=347;
 select @@innodb_lock_wait_timeout;
-set innodb_lock_wait_timeout=1;
+set innodb_lock_wait_timeout=10;
 select @@innodb_lock_wait_timeout;
 
 connect (c,localhost,root,,);
 connection c;
+
 select @@innodb_lock_wait_timeout;
-connection default;
+
 disconnect c;
+--source include/wait_until_disconnected.inc
 
 connection a;
+--replace_result $connection_b_id <connection_b_id>
+eval SET @connection_b_id = $connection_b_id;
 create table t1(a int primary key)engine=innodb;
 begin;
 insert into t1 values(1),(2),(3);
@@ -32,7 +37,37 @@ connection b;
 --send
 select * from t1 for update;
 
+# Observation on information_schema.processlist (2010-12 mysql-5.5)
+# -----------------------------------------------------------------
+# As soon as the server started the execution of the
+#   connection a: --send   select ... for update
+#   High parallel load could delay this up to two seconds.
+# and before either
+# - the innodb_lock_wait_timeout was exceeded
+#   -> connection b reap gets ER_LOCK_WAIT_TIMEOUT
+# or
+# - connection a commits, the lock disappears and the statement
+#   of connection b finishes
+#   -> connection b reap gets success + result set
+# we see within information_schema.processlist for connection b a row
+#    command  state        info
+#    Query    Sending data select * from t1 for update
+# The highest time value seen was @@innodb_lock_wait_timeout + 1.
+# Please note that there is unfortunately nothing which says
+# that we are just waiting for a lock.
+
 connection a;
+# In order to ensure that the execution of
+#    connection b: select * from t1 for update
+# has really started and is most probably waiting for the lock now we poll on
+# information_schema.processlist.
+# Also our current session innodb_lock_wait_timeout of 10 seconds should big
+# enough to prevent that connection b ends up with getting ER_LOCK_WAIT_TIMEOUT.
+#
+let $wait_timeout= 10;
+let $wait_condition= SELECT COUNT(*) = 1 FROM information_schema.processlist
+WHERE id = @connection_b_id AND INFO = 'select * from t1 for update';
+--source include/wait_condition.inc
 commit;
 
 connection b;
@@ -43,21 +78,39 @@ begin;
 insert into t1 values(4);
 
 connection b;
+set innodb_lock_wait_timeout=3;
+# 3 seconds should be big enough that the wait routine of connection a will
+# hit the time span where our next statement is visible within the
+# information_schema.processlist.
 --send
 select * from t1 for update;
 
 connection a;
-sleep 2;
+# Wait till the execution of the connection b statement was started.
+let $wait_timeout= 10;
+let $wait_condition= SELECT COUNT(*) = 1 FROM information_schema.processlist
+WHERE id = @connection_b_id AND INFO = 'select * from t1 for update';
+--source include/wait_condition.inc
+# Wait till the execution of the connection b statement has ended.
+let $wait_timeout= 10;
+let $wait_condition= SELECT COUNT(*) = 1 FROM information_schema.processlist
+WHERE id = @connection_b_id AND INFO IS NULL;
+--source include/wait_condition.inc
+# Give "commit" though this must be too late for the statement of connection b.
 commit;
 
 connection b;
 --error ER_LOCK_WAIT_TIMEOUT
 reap;
-drop table t1;
+
+disconnect b;
+--source include/wait_until_disconnected.inc
+
+connection a;
+disconnect a;
+--source include/wait_until_disconnected.inc
 
 connection default;
-
-disconnect a;
-disconnect b;
-
-eval set global innodb_lock_wait_timeout=$timeout;
+drop table t1;
+--replace_result $initial_timeout <initial_timeout>
+eval set global innodb_lock_wait_timeout=$initial_timeout;