Bug #25129 | 5.1.14 mysql_fix_privilege_tables does not update privilege tables from 5.0.22 | ||
---|---|---|---|
Submitted: | 18 Dec 2006 4:12 | Modified: | 24 Mar 2009 12:25 |
Reporter: | Arjen Lentz | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | MySQL Server: Installing | Severity: | S2 (Serious) |
Version: | 5.1.14 | OS: | Any |
Assigned to: | Daniel Fischer | CPU Architecture: | Any |
Tags: | events, grants, mysql_fix_privilege_tables |
[18 Dec 2006 4:12]
Arjen Lentz
[18 Dec 2006 11:49]
MySQL Verification Team
Thank you for the bug report.
[24 Mar 2009 9:50]
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/70155 2828 He Zhenxing 2009-03-24 BUG#25129 Using relay-log and relay-log-index without values produces unexpected results. Options loaded from config files were added before command line arguments, and they were parsed together, which could interprete the following: option-a option-b as --option-a=--option-b if 'option-a' requires a value, and caused confusing. Because all options that requires a value are always given in the form '--option=value', so it's an error if there is no '=value' part for such an option read from config file. This patch added a separator to separate the arguments from config files and that from command line, so that they can be handled differently. And report an error for options loaded from config files that requires a value and is not given in the form '--option=value'.
[24 Mar 2009 11:50]
Arjen Lentz
So the status of this bugreport is "can't repeat" even though a complete script for reproducing the problem was provided - and yet a patch was just committed? Is the patch related to this bug? Then the status is wrong.... there's a logic/status error somewhere - please fix/clarify? Thanks
[24 Mar 2009 11:54]
Daniel Fischer
The status is "can't repeat" because the complete script failed to reproduce the error in 2007. The above commit was erroneously assigned to this bug report. The patch is for bug#25192.
[24 Mar 2009 11:59]
Arjen Lentz
A bugreport should be repeated on the version it's reported on, and that defines its repeatability. If the problem then happens to not occur in a later version, that can be noted - as in it's been fixed in a later version without an explicit patch. And then the bug can be closed as fixed. Right? Seems logical. "Can't repeat" is confusing, it would indicate that the problem didn't really exist in the version it was reported for. And that would be an incorrect assertion, that could cause trouble in the real world should someone encounter a similar problem and find this bug and see what's been going on with it.
[24 Mar 2009 12:01]
Daniel Fischer
Please read the history of this report. The bug was reported for 5.1.14 and tested against 5.1.14.
[24 Mar 2009 12:11]
Arjen Lentz
I'm sorry, but your view of this may not be the same as what the rest of the world sees. Non-MySQL employees cannot see when status was changed, nor internal messages. From the public info, there's no way to tell on which version things were tested, nor when, nor by whom. Miguel said thank you for the report, the issue is assigned to Daniel, and the status is Can't repeat. Non of those fact are actually explicitly connected to eacho ther either directly or by causality.
[24 Mar 2009 12:15]
Daniel Fischer
Oops, my bad. There is a specific comment about not being able to reproduce this bug with 5.1.14 that is hidden.
[24 Mar 2009 12:25]
Arjen Lentz
Righty. IIRC you can flick a toggle on an individual comment to make it visible.
[25 Jul 2010 1:17]
Jose Fonseca
I'm a big ashamed of reporting that after running mysql_fix_privilege_tables everything worked just fine... At least my report should not be considered here, it works just fine on Mac OS X 10.6.3