| Bug #39484 | main.concurrent_innodb_safelog fails sporadically | ||
|---|---|---|---|
| Submitted: | 16 Sep 2008 15:38 | Modified: | 14 Jan 2013 10:11 |
| Reporter: | Alexander Nozdrin | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | Tests: Server | Severity: | S3 (Non-critical) |
| Version: | 6.0-TRUNK,5.4 | OS: | Any |
| Assigned to: | Assigned Account | CPU Architecture: | Any |
| Tags: | pushbuild, sporadic, test failure | ||
[13 Feb 2009 21: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/66304 2754 Horst Hunger 2009-02-13 Fix for bug#39484: I increased the get_lock timeout to 300 seconds as 10 second are too short for machines with low performance and a release_lock may end up with NULL due to a failed get_lock. I also replaced the sleeps by wait condition.
[18 Feb 2009 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/66717 2838 Tomas Ulin 2009-02-17 disabled test: Bug #39484 main.concurrent_innodb_safelog fails sporadically modified: mysql-test/t/disabled.def
[18 Feb 2009 8:45]
Bugs System
Pushed into 5.1.32-ndb-6.2.17 (revid:tomas.ulin@sun.com-20090218084425-guqwr1xa34ctwi4j) (version source revid:tomas.ulin@sun.com-20090217173919-31hlyng1rnpu05b8) (merge vers: 5.1.32-ndb-6.2.17) (pib:6)
[18 Feb 2009 8:48]
Bugs System
Pushed into 5.1.32-ndb-6.3.23 (revid:tomas.ulin@sun.com-20090218084629-1abu96q2a8ii8fac) (version source revid:tomas.ulin@sun.com-20090218084629-1abu96q2a8ii8fac) (merge vers: 5.1.32-ndb-6.3.23) (pib:6)
[18 Feb 2009 8:49]
Bugs System
Pushed into 5.1.32-ndb-6.4.3 (revid:tomas.ulin@sun.com-20090218084745-9oypy4i4nzplzv6j) (version source revid:tomas.ulin@sun.com-20090218084745-9oypy4i4nzplzv6j) (merge vers: 5.1.32-ndb-6.4.3) (pib:6)
[20 Feb 2009 7:23]
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/66986 2754 Horst Hunger 2009-02-20 2. fix for bug#39484: I resetted the timeout values of get_lock as they have no influence on the actual bug. Due to bug 32782 I added NULL as value to the release_lock as being successful. I also replaced the first 2 "sleep 1" by wait conditions. the last 2 sleeps have not been replaced as I have not found a proper condition leading to deterministic results. All is described in comments.
[23 Feb 2009 10:17]
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/67153 2754 Horst Hunger 2009-02-23 2. fix for bug#39484: I resetted the timeout values of get_lock as they have no influence on the actual bug. Due to bug 32782 I replaced "SELECT release_lock" by "DO release_lock" to catch the varying results as being successful. I also replaced the first 2 "sleep 1" by wait conditions. the last 2 sleeps have not been replaced as I have not found a proper condition leading to deterministic results. All is described in comments.
[3 Mar 2009 14:59]
Matthias Leich
Results of the review:
1. I also have no idea how to replace the remaining sleeps
2. Formal stuff:
1. Line 14 "Hallo" -> "Hello"
2. Line 120,130,...
"proably" -> "probably"
"bug 32782" -> "Bug#32782 User lock hash fails to find lock"
"bug#39484" -> "Bug#39484 main.concurrent_innodb_safelog
fails sporadically"
The main reasons (bug title is here sufficient) must
be mentioned.
A reader should find all important information within
the test and not be forced to look into the Bugs DB.
IMHO a unification of "bug writing style" is strongly
recommended.
-> Bug#nnnnn <Title>
If this is not foillowed tests look chaotic and ugly.
3. Line 94, ...
Please remove the trailing spaces
3. The
DO release_lock("hello");
DO release_lock("hello2");
at begin and end of test do not have the intended effect
because the manual says
RELEASE_LOCK(str)
Releases the lock named by the string str that was
obtained with GET_LOCK().
Returns 1 if the lock was released,
0 if the lock was not established by this thread
(in which case the lock is not released).
Protocol of my experiment:
DO release_lock("hello");
CREATE USER mysqltest@localhost;
"# Establish connection thread1 (user=mysqltest)
SELECT get_lock("hello",3);
get_lock("hello",3)
1
"# Switch to connection default
SELECT release_lock("hello");
release_lock("hello")
0 <--------- !!!
SELECT get_lock("hello",3);
get_lock("hello",3)
0 < -------- !!!
Please remove them all.
[14 Jan 2013 10:11]
Erlend Dahl
Fixed in 5.6.

Description: main.concurrent_innodb_safelog fails sporadically as follows: @@ -72,7 +72,7 @@ ** Release the lock and collect result from update on thread 2 select release_lock("hello"); release_lock("hello") -1 +NULL ** Table should have eta updates where tipo=11 but updates made by ** thread 1 shouldn't be visible yet. select * from t1; The bug reported after the failure in mysql-6.0 on Mon Sep 15 20:48:13 2008 (http://tinyurl.com/6exj73) on sapsrv2. How to repeat: http://tinyurl.com/5qzrkh