| Bug #19158 | pushbuild fails on SLES9 x86-max ps_row fails on rpl_row_log_innodb | ||
|---|---|---|---|
| Submitted: | 18 Apr 2006 3:45 | Modified: | 11 May 2006 11:53 |
| Reporter: | Elliot Murphy | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
| Version: | mysql-5.1-new | OS: | Linux (Linux) |
| Assigned to: | Jonathan Miller | CPU Architecture: | Any |
[18 Apr 2006 4: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/5043
[18 Apr 2006 4:36]
Elliot Murphy
Pushed temporary fix, need to do proper fix with wait_slave_status.inc
[10 May 2006 22: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/6228
[11 May 2006 11:53]
Jonathan Miller
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.
If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information
about accessing the source trees is available at
http://www.mysql.com/doc/en/Installing_source_tree.html
Description: rpl_row_log_innodb [ fail ] Errors are (from /dev/shm/var-ps_row-6/log/mysqltest-time) : mysqltest: In included file "./extra/rpl_tests/rpl_log.test": At line 80: could not sync with master ('select master_pos_wait('master-bin.000002', 201)' returned NULL) (the last lines may be the most important ones) Result from queries before failure can be found in r/rpl_row_log_innodb.log Killing Possible Leftover Processes How to repeat: Test passes on local machine, fails in pushbuild. The failure happens immediately after start slave is issued, and then select master_pos_wait() returns NULL, which indicates that the slave thread is not yet started. This is a race condition in the test case, and harmless in the real world. Suggested fix: Make the test more resilient to the time it takes to start the slave thread. Easy fix: add a sleep Better fix: use the new wait_slave_status.inc solution to poll slave status and exit cleanly when thread starts.