| Bug #50167 | backup_triggers_and_events fails with: "backup wait timeout has expired for..." | ||
|---|---|---|---|
| Submitted: | 8 Jan 2010 0:18 | Modified: | 11 Jan 2013 12:23 |
| Reporter: | Luis Manuel Oliveira Soares | Email Updates: | |
| Status: | Unsupported | Impact on me: | |
| Category: | Tests: Backup | Severity: | S3 (Non-critical) |
| Version: | 5.6.0 (mysql-backup-backport) | OS: | Any |
| Assigned to: | Luis Manuel Oliveira Soares | CPU Architecture: | Any |
| Tags: | backport, Backup | ||
[8 Jan 2010 0: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/96338 3039 Luis Soares 2010-01-08 BUG#50167: backup_triggers_and_events fails with: "backup wait timeout has expired for..." The test fails because the THD::backup_wait_timeout variable is not initialized with default value (BACKUP_WAIT_TIMEOUT_DEFAULT). It seems that a small portion of some patch was not backported properly. In particular, the one that affects the last hunk for this cset: tree: mysql-6.0-backup revision-id: ingo.struewing@sun.com-20081216115134-zot1nv8bix0ixk2h Originally, backup_wait_timeout had been introduced by patch: tree: mysql-6.0-backup revision-id: revision-id: cbell@mysql.com-20080819153529-2q1xr9zeam8iltai and later changed by the cset mentioned in the first place. Maybe that caused bigger entropy while handling the backport and the small part of the patch was inadvertently missed/forgotten/left out... We fix this by deploying the missing initialization of backup_wait_timeout with the default value.
[8 Jan 2010 11:01]
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/96362 3039 Luis Soares 2010-01-08 BUG#50167: backup_triggers_and_events fails with: "backup wait timeout has expired for..." The test fails because the THD::backup_wait_timeout variable is not initialized with default value (BACKUP_WAIT_TIMEOUT_DEFAULT). It seems that a small portion of some patch was not backported properly. In particular, the one that affects the last hunk for this cset: tree: mysql-6.0-backup revision-id: ingo.struewing@sun.com-20081216115134-zot1nv8bix0ixk2h Originally, backup_wait_timeout had been introduced by patch: tree: mysql-6.0-backup revision-id: revision-id: cbell@mysql.com-20080819153529-2q1xr9zeam8iltai and later changed by the cset mentioned in the first place. Maybe that caused bigger entropy while handling the backport and the small part of the patch was inadvertently missed/forgotten/left out... We fix this by deploying the missing initialization of backup_wait_timeout with the default value. NOTE: this was done by applying original patch: revid: ingo.struewing@sun.com-20081216115134-zot1nv8bix0ixk2h against the mysql-backup-backport tree and solving the conflicts.
[8 Jan 2010 11:09]
Ingo Strüwing
Approved. No second reviewer needed. It's a merge of an existing revision.
[8 Jan 2010 11:35]
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/96372 3043 Luis Soares 2010-01-08 [merge] BUG#50167: merge to latest branch. Seems a cset has merged recently part of this patch, ie, the one that dealt with BACKUP_WAIT_TIMEOUT_DEFAULT. So this merge is just for the remaining hunk.
[8 Jan 2010 11:41]
Luis Manuel Oliveira Soares
Queued in mysql-backup-backport. Push: http://pb2.norway.sun.com/web.py?template=push_details&push=819075
Description: In the current state of affairs of backup backport, the test backup_triggers_and_events is failing with the following output: [...] CURRENT_TEST: backup.backup_triggers_and_events mysqltest: At line 537: query 'reap' failed: 1766: The backup wait timeout has expired for query 'UPDATE bup_trigevt_backup.t1_same SET c2='UPDATE bup_trigevt_backup.t1_same' WHERE c2='INSERT bup_trigevt_backup.t1_same''. [...] Stepping into the execution one finds that while in "Backup_sx_lock::get_shared_lock" the value for thd->backup_wait_timeout is suspiciously very big. This probably suggests that the variable thd->backup_wait_timeout is not properly initialized. How to repeat: 1. bzr clone -r revid:charles.bell@sun.com-20100107142613-tj1gbdmwiyje9f7e $URL_TO_BZR_REPO/mysql-backup-backport 2. cd mysql-backup-backport 3. bash BUILD/compile-pentium64-debug-max 4. cd mysql-test 5. perl mysql-test-run.pl backup.backup_triggers_and_events The test will then fail with the symptom reported. Suggested fix: === modified file 'sql/sql_class.cc' --- sql/sql_class.cc 2009-12-30 17:12:16 +0000 +++ sql/sql_class.cc 2010-01-08 00:10:07 +0000 @@ -464,6 +464,7 @@ derived_tables_processing(FALSE), spcont(NULL), m_parser_state(NULL), + backup_wait_timeout(BACKUP_WAIT_TIMEOUT_DEFAULT), #if defined(ENABLED_DEBUG_SYNC) debug_sync_control(0), #endif /* defined(ENABLED_DEBUG_SYNC) */