Bug #29307 status.test fails with different Table_locks_immediate
Submitted: 22 Jun 2007 17:26 Modified: 20 Aug 2007 17:07
Reporter: Timothy Smith Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Tests Severity:S7 (Test Cases)
Version:4.1, 5.0, 5.1 OS:Any
Assigned to: Timothy Smith CPU Architecture:Any
Tags: pbfail

[22 Jun 2007 17:26] Timothy Smith
Description:
status.test fails fairly often due to this difference in results:

-------------------------------------------------------
*** r/status.result	Fri Jun 22 12:43:29 2007
--- r/status.reject	Fri Jun 22 16:30:18 2007
***************
*** 18,29 ****
  unlock tables;
  show status like 'Table_lock%';
  Variable_name	Value
! Table_locks_immediate	3
! Table_locks_waited	1
  select * from information_schema.session_status where variable_name like 'Table_lock%';
  VARIABLE_NAME	VARIABLE_VALUE
! TABLE_LOCKS_IMMEDIATE	3
! TABLE_LOCKS_WAITED	1
  drop table t1;
  select 1;
  1
--- 18,29 ----
  unlock tables;
  show status like 'Table_lock%';
  Variable_name	Value
! Table_locks_immediate	4
! Table_locks_waited	0
  select * from information_schema.session_status where variable_name like 'Table_lock%';
  VARIABLE_NAME	VARIABLE_VALUE
! TABLE_LOCKS_IMMEDIATE	4
! TABLE_LOCKS_WAITED	0
  drop table t1;
  select 1;
  1
-------------------------------------------------------

The failure first shows up in July 2006 in 5.0-opt, here:

https://intranet.mysql.com/secure/pushbuild/showpush.pl?dir=mysql-5.0-opt&order=46

It shows up in all versions, and seems to primarily happen on powermacg5, although an amd64 linux box and qnx have seen it as well.

How to repeat:
https://intranet.mysql.com/secure/pushbuild/xref.pl?&testname=status&testtext=%25TABLE_LOC...
[27 Jun 2007 3:58] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/29659

ChangeSet@1.2516, 2007-06-26 21:10:51-04:00, dkatz@damien-katzs-computer.local +1 -0
  Bug #29307  	status.test fails with different Table_locks_immediate
  
  Instead of sleeping for a fixed period of time, we wait until the other query is executing.
[28 Jun 2007 9:03] Magnus BlÄudd
I see. It's not possible to wait for the lock/first process  using another query available in 5.0?
[10 Jul 2007 13:26] Bugs System
Pushed into 5.1.21-beta
[10 Jul 2007 13:28] Bugs System
Pushed into 5.0.46
[10 Jul 2007 21:35] Paul DuBois
Test suite change. No changelog entry needed.
[19 Jul 2007 15:48] Bugs System
Pushed into 5.1.21-beta
[16 Aug 2007 1:21] Timothy Smith
I'm re-opening this bug, because it still fails in 5.1 occasionally.  The symptom is different (it's showing up later in the test), but appears to have the same cause.

-------------------------------------------------------
*** C:/cygwin/home/pushbuild/pb1/pb/mysql-5.1-new-maint/731/mysql-5.1.22-beta-pb731/mysql-test/r/status.result	Thu Aug 16 01:14:32 2007
--- C:/cygwin/home/pushbuild/pb1/pb/mysql-5.1-new-maint/731/mysql-5.1.22-beta-pb731/mysql-test/r/status.reject	Thu Aug 16 01:48:21 2007
***************
*** 18,28 ****
  unlock tables;
  show status like 'Table_lock%';
  Variable_name	Value
! Table_locks_immediate	17
  Table_locks_waited	1
  select * from information_schema.session_status where variable_name like 'Table_lock%';
  VARIABLE_NAME	VARIABLE_VALUE
! TABLE_LOCKS_IMMEDIATE	18
  TABLE_LOCKS_WAITED	1
  drop table t1;
  select 1;
--- 18,28 ----
  unlock tables;
  show status like 'Table_lock%';
  Variable_name	Value
! Table_locks_immediate	18
  Table_locks_waited	1
  select * from information_schema.session_status where variable_name like 'Table_lock%';
  VARIABLE_NAME	VARIABLE_VALUE
! TABLE_LOCKS_IMMEDIATE	19
  TABLE_LOCKS_WAITED	1
  drop table t1;
  select 1;
-------------------------------------------------------
[17 Aug 2007 18:44] Timothy Smith
The problem here is that the wait condition actually affects the status variable we're trying to test.  Each time the select query for the wait condition runs, it increases Table_locks_immediate.

Probable solution: augment wait_condition.inc to make available the number of times it had to run the condition query, and subtract that from the value we are checking in the actual test.
[18 Aug 2007 1:31] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/32714

ChangeSet@1.2573, 2007-08-17 19:29:08-06:00, tsmith@ramayana.hindu.god +2 -0
  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.
[18 Aug 2007 8:30] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/32715

ChangeSet@1.2564, 2007-08-18 02:28:08-06:00, tsmith@ramayana.hindu.god +2 -0
  Bug #29307: status.test fails with different Table_locks_immediate
  
  Finish premature patch which was accidentally pushed; remove debugging
  info and correct the test.
[20 Aug 2007 10:20] Bugs System
Pushed into 5.1.22-beta
[20 Aug 2007 17:07] Timothy Smith
Test case change only, no need for documentation