MySQL Bugs: #29307: status.test fails with different Table_locks

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

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...

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.

I see. It's not possible to wait for the lock/first process  using another query available in 5.0?

Pushed into 5.1.21-beta

Pushed into 5.0.46

Test suite change. No changelog entry needed.

Pushed into 5.1.21-beta

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;
-------------------------------------------------------

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.

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.

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.

Pushed into 5.1.22-beta

Test case change only, no need for documentation