| Bug #56618 | Thread_ID is not assigned in ascending sequence (after disconnect) | ||
|---|---|---|---|
| Submitted: | 7 Sep 2010 14:11 | Modified: | 6 Jan 2011 2:50 |
| Reporter: | Joerg Bruehe | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Performance Schema | Severity: | S3 (Non-critical) |
| Version: | 5.5.6-rc | OS: | Linux (icc x86_64) |
| Assigned to: | Marc ALFF | CPU Architecture: | Any |
[29 Sep 2010 15:40]
Davi Arnaut
Looks like this could be a duplicate of Bug#52419.
[29 Sep 2010 15:52]
Joerg Bruehe
According to Davi's analysis, bug#52419 affected 32 bit platforms only, but this one occurred in a 64 bit build. So if this is a duplicate, then 52419 seems to have wider applicability than believed until now.
[29 Sep 2010 15:53]
Davi Arnaut
Huh.. didn't notice the x86_64.. never mind :)
[29 Sep 2010 15:55]
Davi Arnaut
But it might still be worth to take a look at the assembly around where the thread id is incremented.
[1 Dec 2010 10:11]
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/125628 3158 Marc Alff 2010-12-01 Bug#56618 Thread_ID is not assigned in ascending sequence (after disconnect) Before this fix, the test thread_cache failed with spurious failures. The test used: -- disconnect X -- connect Y while assuming that connection Y would reuse connection X slot in the thread cache. For this to happen, the disconnect X operation must be given enough time to complete, otherwise connect Y can be executed in the server before X actually finishes. This fix uses wait conditions to make the test execution more controlled, and more reproductible.
[1 Dec 2010 17:32]
Christopher Powers
Patch approved. Thanks for taking this one.
[1 Dec 2010 18:52]
Marc ALFF
Pushed into: - mysql-5.5-bugteam - mysql-trunk-bugfixing
[5 Dec 2010 12:40]
Bugs System
Pushed into mysql-trunk 5.6.1 (revid:alexander.nozdrin@oracle.com-20101205122447-6x94l4fmslpbttxj) (version source revid:alexander.nozdrin@oracle.com-20101205122447-6x94l4fmslpbttxj) (merge vers: 5.6.1) (pib:23)
[11 Dec 2010 17:02]
Paul DuBois
But not present in any 5.6.x release. Setting report to Need Merge pending push into 5.5.x.
[17 Dec 2010 12:54]
Bugs System
Pushed into mysql-5.5 5.5.9 (revid:georgi.kodinov@oracle.com-20101217124733-p1ivu6higouawv8l) (version source revid:marc.alff@oracle.com-20101201180757-db5woxysu9kenfau) (merge vers: 5.5.8) (pib:24)
[6 Jan 2011 2:50]
Paul DuBois
Changes to test suite. No changelog entry needed.
Description: This test failure is detected in the 5.5.6-rc release build: ===== perfschema.thread_cache [ retry-fail ] Test ended at YYYY-MM-DD HH:MM:SS CURRENT_TEST: perfschema.thread_cache --- /PATH/mysql-test/suite/perfschema/r/thread_cache.result +++ /PATH/mysql-test/suite/perfschema/r/thread_cache.reject @@ -14,7 +14,7 @@ 1 select @thread_id_increment; @thread_id_increment -1 +-26 set global thread_cache_size = 100; show variables like "thread_cache_size"; Variable_name Value mysqltest: Result content mismatch ===== Note that this is the output of $con3_THREAD_ID - $con2_THREAD_ID where connection con3 is established only after con2 was disconnected. The first similar output $con2_THREAD_ID - $con1_THREAD_ID produces the expected output 1, as do all differences of "connection_id"s. How to repeat: It happened when running the test suite, but only on the 4th (or so) build of this version and only on one platform.