Bug #29307: status.test fails with different Table_locks_immediate

When using --log --log-output=table, we increment Table_locks_immediate
with every query.  The wait_condition.inc runs a query a variable number
of times, depending on server load, etc.  This is a problem, when the
test is checking the Table_locks_immediate value.

Fix is to adjust the Table_locks_immediate value based on how many times
the wait_condition query was executed.

mysql-test/include/wait_condition.inc

@@ -17,6 +17,7 @@
 #    let $wait_condition=
 #      SELECT c = 3 FROM t;
 #    --source include/wait_condition.inc
+#    --echo Executed the test condition $wait_condition_reps times
 #
 # EXAMPLE
 #    events_bugs.test, events_time_zone.test
@@ -33,9 +34,13 @@ if ($wait_timeout)
 # calls, and default will be used instead.
 let $wait_timeout= 0;
 
+# Keep track of how many times the wait condition is tested
+# This is used by some tests (e.g., main.status)
+let $wait_condition_reps= 0;
 while ($wait_counter)
 {
     let $success= `$wait_condition`;
+    inc $wait_condition_reps;
     if ($success)
     {
         let $wait_counter= 0;

mysql-test/t/status.test

+# This test requires that --log-output includes 'table', and the general
+# log is on
+
 # embedded server causes different stat
 -- source include/not_embedded.inc
 
@@ -8,33 +11,56 @@ connect (con1,localhost,root,,);
 connect (con2,localhost,root,,);
 
 flush status;
+
+# Logging to the general query log table (--log-output=table --log) increments
+# Table_locks_immediate with each query, so here Immediate becomes 1
 show status like 'Table_lock%';
+# ++Immediate = 2
 select * from information_schema.session_status where variable_name like 'Table_lock%';
+
 connection con1;
+# ++Immediate = 3
 SET SQL_LOG_BIN=0;
 --disable_warnings
+# ++Immediate = 4
 drop table if exists t1;
 --enable_warnings
 
+# ++Immediate = 5
 create table t1(n int) engine=myisam;
+# Immediate + 2 = 7
 insert into t1 values(1);
+
 connection con2;
+# Immediate + 2 = 9
 lock tables t1 read;
+# ++Immediate = 10
 unlock tables;
+# Immediate + 2 = 12
 lock tables t1 read;
+
 connection con1;
+# ++Immediate = 13
 let $ID= `select connection_id()`;
+# ++Immediate = 14 (Not +2, because this increments Table_locks_waited)
 --send
 update t1 set n = 3;
+
 connection con2;
 # wait for the other query to start executing
 let $wait_condition= select 1 from INFORMATION_SCHEMA.PROCESSLIST where ID = $ID and STATE = "Locked";
+# ++Immediate = 15 + $wait_condition_reps (wait_condition.inc does one select
+# in addition to the wait condition)
 --source include/wait_condition.inc
+# ++Immediate = 16 + $wait_condition_reps
 unlock tables;
+
 connection con1;
 reap;
-show status like 'Table_lock%';
-select * from information_schema.session_status where variable_name like 'Table_lock%';
+# ++Immediate = 17 + $wait_condition_reps
+show status like 'Table_locks_waited';
+# ++Immediate = 18 + $wait_condition_reps
+eval select variable_value - $wait_condition_reps as Immediate from information_schema.session_status where variable_name like 'Table_locks_immediate';
 drop table t1;
 
 disconnect con2;