Bug #40143 | federated.federated_server fails sporadically in pushbuild | ||
---|---|---|---|
Submitted: | 19 Oct 2008 14:06 | Modified: | 30 Jan 2009 17:43 |
Reporter: | Sven Sandberg | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Tests: Engine | Severity: | S7 (Test Cases) |
Version: | 5.1-rpl, 6.0-rpl | OS: | Any |
Assigned to: | Luis Soares | CPU Architecture: | Any |
Tags: | federated_server, pushbuild, pushbuild, sporadic, test failure |
[19 Oct 2008 14:06]
Sven Sandberg
[21 Jan 2009 11:29]
Luis Soares
Actually, it also fails with a different variation of the other two messages reported: federated.federated_server [ fail ] CURRENT_TEST: federated.federated_server --- /data0/pushbuild/pb/bzr_mysql-6.0-rpl/80/mysql-6.0.8-alpha-pb80/mysql-test/suite/federated/federated_server.result 2008-10-03 10:53:13.000000000 +0300 +++ /data0/pushbuild/pb/bzr_mysql-6.0-rpl/80/mysql-6.0.8-alpha-pb80/mysql-test/suite/federated/federated_server.reject 2008-10-03 11:37:12.000000000 +0300 @@ -277,9 +277,9 @@ call p1(); call p1(); e > 0 -1 +0 e > 0 -1 +0 drop procedure p1; drop server if exists s; DROP TABLE IF EXISTS federated.t1; --------------- ref: https://intranet.mysql.com/secure/pushbuild/showpush.pl?dir=bzr_mysql-6.0-rpl&order=80
[21 Jan 2009 11:33]
Luis Soares
See also BUG#25721 .
[21 Jan 2009 14:01]
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/63724 2785 Luis Soares 2009-01-21 BUG#40143 federated.federated_server fails sporadically in pushbuild The original goal of the test, as reported on BUG #25721, is to check whether a deadlock happens or not when concurrently CREATING/ALTERING/DROPPING the same server. For that a procedure (p1) is created that runs the exact same CREATE/ALTER/DROP statements for 10K iterations and two different connections (threads - t1 and t2) call p1 concurrently. At the end of the 10K iterations, the test checks if there was errors while running the loop (SELECT e >0). The problem is that In some cases it may happen that one thread, t1, gets scheduled to execute with just enough time to complete the iteration and never bumps into the other thread t2. Meaning that t1 will never run into an SQL exception. On the other hand, the other thread, t2, may run into t1 and never issue any/part of its own statements because it will throw an SQLEXCEPTION. This is probably the case for failures where only one value differs. Furthermore, there is a third scenario: both threads are scheduled to run interleaved for each iteration (or even one thread completes all iterations before the other starts). In this case, both will succeed without any error. This is probably the case for the failure that reports two different values. The solution is to replace '>' with '>=' as the test case is checking for deadlocks and not errors. A timeout should occur if the error that the test is checking surfaces.
[21 Jan 2009 14:28]
Alfranio Junior
Patch approved.
[22 Jan 2009 13:08]
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/63809 2717 Luis Soares 2009-01-22 BUG#40143 federated.federated_server fails sporadically in pushbuild The original goal of the test, as reported on BUG #25721, is to check whether a deadlock happens or not when concurrently CREATING/ALTERING/DROPPING the same server. For that a procedure (p1) is created that runs the exact same CREATE/ALTER/DROP statements for 10K iterations and two different connections (threads - t1 and t2) call p1 concurrently. At the end of the 10K iterations, the test checks if there was errors while running the loop (SELECT e >0). The problem is that In some cases it may happen that one thread, t1, gets scheduled to execute with just enough time to complete the iteration and never bumps into the other thread t2. Meaning that t1 will never run into an SQL exception. On the other hand, the other thread, t2, may run into t1 and never issue any/part of its own statements because it will throw an SQLEXCEPTION. This is probably the case for failures where only one value differs. Furthermore, there is a third scenario: both threads are scheduled to run interleaved for each iteration (or even one thread completes all iterations before the other starts). In this case, both will succeed without any error. This is probably the case for the failure that reports two different values. This patch addresses the failure in pushbuild by removing the error counting and the printout (SELECT > 0) at the end of the test. A timeout should occur if the error that the test is checking surfaces.
[30 Jan 2009 13:29]
Bugs System
Pushed into 6.0.10-alpha (revid:luis.soares@sun.com-20090129165607-wiskabxm948yx463) (version source revid:luis.soares@sun.com-20090129163120-e2ntks4wgpqde6zt) (merge vers: 6.0.10-alpha) (pib:6)
[30 Jan 2009 15:09]
Bugs System
Pushed into 5.1.32 (revid:luis.soares@sun.com-20090129165946-d6jnnfqfokuzr09y) (version source revid:luis.soares@sun.com-20090122130758-tso0ljc64j8rj6v1) (merge vers: 5.1.31) (pib:6)
[30 Jan 2009 17:43]
Paul DuBois
Test case changes. No changelog entry needed.
[17 Feb 2009 14:56]
Bugs System
Pushed into 5.1.32-ndb-6.3.23 (revid:tomas.ulin@sun.com-20090217131017-6u8qz1edkjfiobef) (version source revid:tomas.ulin@sun.com-20090203133556-9rclp06ol19bmzs4) (merge vers: 5.1.32-ndb-6.3.22) (pib:6)
[17 Feb 2009 16:44]
Bugs System
Pushed into 5.1.32-ndb-6.4.3 (revid:tomas.ulin@sun.com-20090217134419-5ha6xg4dpedrbmau) (version source revid:tomas.ulin@sun.com-20090203133556-9rclp06ol19bmzs4) (merge vers: 5.1.32-ndb-6.3.22) (pib:6)
[17 Feb 2009 18:20]
Bugs System
Pushed into 5.1.32-ndb-6.2.17 (revid:tomas.ulin@sun.com-20090217134216-5699eq74ws4oxa0j) (version source revid:tomas.ulin@sun.com-20090201210519-vehobc4sy3g9s38e) (merge vers: 5.1.32-ndb-6.2.17) (pib:6)