Bug #53101 | binlog.binlog_tmp_table fails on sol10 sparc64 max in parallel mode | ||
---|---|---|---|
Submitted: | 23 Apr 2010 9:04 | Modified: | 8 May 2010 17:04 |
Reporter: | Alexander Nozdrin | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Tests: Replication | Severity: | S7 (Test Cases) |
Version: | M3 (Celosia) | OS: | Any |
Assigned to: | Luis Soares | CPU Architecture: | Any |
Tags: | pb2, test failure |
[23 Apr 2010 9:04]
Alexander Nozdrin
[24 Apr 2010 8:31]
Sveta Smirnova
Thank you for the report. Verified using PB logs. Not repeatable on Support box.
[26 Apr 2010 14:38]
Luis Soares
How to repeat: 1. bzr clone mysql-next-mr 2. cd mysql-next-mr 3. (build) 4. cd mysql-test 5. perl mtr --mysqld=--binlog-format=mixed binlog_stm_ctype_ucs binlog_tmp_table
[26 Apr 2010 14: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/106541 3152 Luis Soares 2010-04-26 BUG#53101: binlog.binlog_tmp_table fails on sol10 sparc64 max in parallel mode The failure has nothing to do with parallel, but rather on the order the tests are executed. In this case, the test binlog_tmp_table (lets call it test2) was not ensuring that the binary logs would be reset when it started. Later the test issues a mysqlbinlog .../master-bin.000002 | mysql ... If the test that was executed before this one (lets call it test1) had issued a flush logs, then the file in use in test1 (master-bin.000002) would not actually match the one that was expected. Eventually, this would cause the statements logged in test1 to be replayed, instead of the ones logged in the beginning of test2. We fix this by: 1. adding RESET MASTER to the beginning of binlog_tmp_table 2. setting dynamically the file to use in binlog_tmp_table Only #1 was needed, but the two make the tests cases more robust.
[27 Apr 2010 11:26]
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/106626 3023 Luis Soares 2010-04-27 BUG#53101: binlog.binlog_tmp_table fails on sol10 sparc64 max in parallel mode The failure has nothing to do with parallel, but rather on the order the tests are executed. In this case, the test binlog_tmp_table (lets call it test2) was not ensuring that the binary logs would be reset when it started. Later the test issues a mysqlbinlog .../master-bin.000002 | mysql ... If the test that was executed before this one (lets call it test1) had issued a flush logs, then the file in use in test1 (master-bin.000002) would not actually match the one that was expected. Eventually, this would cause the statements logged in test1 to be replayed, instead of the ones logged in the beginning of test2. We fix this by: 1. adding RESET MASTER to the beginning of binlog_tmp_table 2. setting dynamically the file to use in binlog_tmp_table Only #1 was needed, but the two make the tests cases more robust.
[27 Apr 2010 15:19]
Luis Soares
Pushed to mysql-trunk-bugfixing, mysql-next-mr-bugfixing, mysql-6.0-codebase-bugfixing: - http://pb2.norway.sun.com/web.py?template=push_details&push=1201553 - http://pb2.norway.sun.com/web.py?template=push_details&push=1201903 - http://pb2.norway.sun.com/web.py?template=push_details&push=1202232
[7 May 2010 9:21]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100507091908-vqyhpwf2km0aokno) (version source revid:alik@sun.com-20100507091737-12vceffs11elb25g) (merge vers: 6.0.14-alpha) (pib:16)
[7 May 2010 9:22]
Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100507091655-349gwq21ursz8y4p) (version source revid:alik@sun.com-20100507091655-349gwq21ursz8y4p) (merge vers: 5.5.5-m3) (pib:16)
[7 May 2010 9:23]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100507091823-nzao4h3qosau4tin) (version source revid:alik@sun.com-20100507091720-ib9r8uny2aeazvas) (pib:16)
[8 May 2010 17:04]
Paul DuBois
Changes to test cases. No changelog entry needed.