| Bug #46785 | main.truncate_coverage fails sporadically | ||
|---|---|---|---|
| Submitted: | 18 Aug 2009 13:17 | Modified: | 7 Jul 2010 19:36 |
| Reporter: | Alexander Nozdrin | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: General | Severity: | S3 (Non-critical) |
| Version: | Betony | OS: | Any |
| Assigned to: | Dmitry Lenev | CPU Architecture: | Any |
| Tags: | experimental, pb2, sporadic, test failure, tf54 | ||
[18 Aug 2009 20:03]
Bugs System
Pushed into 5.4.4-alpha (revid:alik@sun.com-20090818200211-fx1sq0284n261fb3) (version source revid:alik@sun.com-20090818195941-6oey1m1lj03gzv4x) (merge vers: 5.4.4-alpha) (pib:11)
[19 Aug 2009 7:58]
Sveta Smirnova
Thank you for the report. Verified as described on Mac OSX Tiger 32-bit with running `./mtr truncate_coverage --repeat=1000`
[8 Sep 2009 19:52]
Ingo Strüwing
This could perhaps be fixed together with Bug#37780 (main.kill fails randomly). KILL is unreliable. The fix will improve it, but does not make it completely reliable. We may need some sort of sleep before checking if the target thread noticed the kill. We could repeat the kill, if it didn't arrive within the wait time. One possible idea might be to have a sync point behind the waiting loop, which is to be interrupted and let it emit a signal, which another connection waits for, using a timeout. That way we won't have a sleep in the normal case, where the kill succeeds. $mysql_errno might be used to check if waiting for the signal timed out.
[11 Jun 2010 13:33]
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/110841 3053 Dmitry Lenev 2010-06-11 Fix for bug #46785 "main.truncate_coverage fails sporadically". Races in truncate_coverage.test have caused its sporadical failures. In the test case we have tried to kill truncate statement being executed in the first connection which was waiting for X metadata lock on table being locked by the second connection. Since we have released metadata lock held by the second connection right after issuing KILL statement sometimes TRUNCATE TABLE managed to acquire X lock before it has noticed that it was killed. In this case TRUNCATE TABLE was successfully executed till its end and this fact has caused test failure since this statement didn't return expected error in such case. This patch addresses the problem by not releasing metadata locks in the second connections prematurely.
[22 Jun 2010 13:08]
Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100622130139-u05awgya93zvbsop) (version source revid:marko.makela@oracle.com-20100603095032-v5ptkkzt1bhz0m1d) (merge vers: 5.1.48) (pib:16)
[22 Jun 2010 13:09]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100622130623-r7yhm89fz9n5t9nb) (version source revid:alik@sun.com-20100622130528-187gd949sa9b6pa6) (pib:16)
[7 Jul 2010 19:36]
Paul DuBois
Changes to test cases. No changelog entry needed.
Description: main.truncate_coverage fails sporadically in PB2. ------------------------------------------------------------------- Symptoms: main.truncate_coverage [ fail ] Test ended at 2009-08-06 22:36:54 CURRENT_TEST: main.truncate_coverage mysqltest: At line 62: query 'reap' succeeded - should have failed with errno 1317... ------------------------------------------------------------------- The test case will be marked as experimental. How to repeat: XRef2: http://pb2.norway.sun.com/web.py?template=mysql_show_test_failure&test_failure_id=2277486&...