Bug #39749 | main.backup_timeout fails sporadically on OS X | ||
---|---|---|---|
Submitted: | 30 Sep 2008 6:37 | Modified: | 2 Feb 2009 17:23 |
Reporter: | Alexander Nozdrin | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Tests: Server | Severity: | S3 (Non-critical) |
Version: | 6.0-TRUNK | OS: | MacOS (powermacg5) |
Assigned to: | Ingo Strüwing | CPU Architecture: | Any |
Tags: | pushbuild, sporadic, test failure, timeout |
[30 Sep 2008 6:37]
Alexander Nozdrin
[4 Dec 2008 15:13]
Ingo Strüwing
The system variable "backup_wait_timeout" is a mystery to me. - It's documentation in the reference manual is plain wrong. It is not BACKUP or RESTORE which time out on DDLs, but it is DDLs, which time out when BACKUP or RESTORE is running. However, it's a legitimate question: Why not both ways? The reason for the variable, as decribed in Bug #33414 (Backup: DDL hangs indefinitely if ongoing backup), is to give the DBA an error message instead of letting his DDL hang for hours. Why wouldn't that apply to BACKUP and RESTORE too? - The manual and initial description for the value of zero is that it means "no timeout". On May 1 once in a sudden it has been redefined as "timeout immediately". I found some email thread with a suggestion like this, but no agreement about it. There are some mentions of discussions with Peter, but they are not referenced anywhere. Digging in the mail archives, I found it. Anyway, this is poorly documented. The test case has a comment: "test timeout for a session with a timeout, and a session with no timeout (backup_wait_timeout = 0)", which suggests that zero means "no timeout". This is pretty confusing. - I am sceptic about the default value. Especially as it cannot be set globally. It means that every DDL times out after 50 seconds when BACKUP or RESTORE is running. If a user wants to change it, he needs to set it for every connection separately. - When constructing a THD, we use a default value of 50, while on SET backup_wait_timeout=DEFAULT, we use BACKUP_WAIT_TIMEOUT_DEFAULT. - The variable type is LONG and the maximum value is defined as LONG_MAX/1000 == 2147483, which is correct only on systems with 32-bit long. The factor of 1000 isn't explained, not intuitive, and I don't understand it. Why not limit it to LONG_MAX, or better even implicitly to ULONG_MAX? - The use of ulong_value and ulonglong_value looks suspicious. Indeed we have Bug#40808 (The backup_wait_timeout variable is not working on powermac platform), which does probably fail on this inconsistency. And since backup_timeout.test fails on the same platform, because of a backup_wait_timeout value of zero, after assignment of 100, this is probably the same cause. - I do not understand, why a session-only value is copied into thd->sys_var_tmp (in sys_var_backup_wait_timeout::value_ptr()). It looks like wasted cycles. Not a real issue, but still odd.
[4 Dec 2008 19:40]
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/60649 2737 Ingo Struewing 2008-12-04 Bug#39749 - main.backup_timeout fails sporadically on OS X Bug#40808 - The backup_wait_timeout variable is not working on powermac platform backup_timeout.test failed on POWER processors. Due to word ordering within a long long variable, the code was not portable between different processor types. Fixed by reworking the implementation of sys_var_backup_wait_timeout. Re-enabled backup_timeout.test. Included are unrelated fixes to get rid of compiler warnings.
[5 Dec 2008 20:41]
Ingo Strüwing
Sorry, the patch doesn't work on sparc. Working on a new one.
[5 Dec 2008 21:38]
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/60781 2737 Ingo Struewing 2008-12-05 Bug#39749 - main.backup_timeout fails sporadically on OS X Bug#40808 - The backup_wait_timeout variable is not working on powermac platform backup_timeout.test failed on POWER processors. Due to word ordering within a long long variable, the code was not portable between different processor types. Fixed by reworking the implementation of sys_var_backup_wait_timeout. Re-enabled backup_timeout.test. Included are unrelated fixes to get rid of compiler warnings.
[8 Dec 2008 20:47]
Chuck Bell
Patch approved pending fix of compiler warning on Windows. set_var.cc(3073) : warning C4244: '=' : conversion from 'ulonglong' to 'ulong', possible loss of data
[15 Dec 2008 10:00]
Jørgen Løland
Good to push
[16 Dec 2008 11:51]
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/61753 2740 Ingo Struewing 2008-12-16 Bug#39749 - main.backup_timeout fails sporadically on OS X Bug#40808 - The backup_wait_timeout variable is not working on powermac platform backup_timeout.test failed on POWER processors. Due to word ordering within a long long variable, the code was not portable between different processor types. Fixed by reworking the implementation of sys_var_backup_wait_timeout. Re-enabled backup_timeout.test. Included are unrelated fixes to get rid of compiler warnings.
[16 Dec 2008 11:56]
Ingo Strüwing
Patch queued to 6.0-backup.
[2 Feb 2009 16:07]
Bugs System
Pushed into 6.0.10-alpha (revid:sergefp@mysql.com-20090202090240-dlkxhmc1asrar5rl) (version source revid:sergefp@mysql.com-20090129100938-qvke7a9krg24l8pl) (merge vers: 6.0.10-alpha) (pib:6)
[2 Feb 2009 17:23]
Paul DuBois
Noted in 6.0.10 changelog. The implementation of the backup_wait_timeout system variable was machine dependent and did not work correctly on big-endian machines. Also revised the documentation for backup_wait_timeout to say: The number of seconds DDL statements wait for a BACKUP DATABASE or RESTORE operation before aborting with an error. The default value is 50. A value of 0 means "immediate timeout."