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: | |
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
[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