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:
None 
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
Description:
The mysql_fix_privilege_tables script in 5.1.14 does not work correctly. In fact, it crashes the server.

===
Original errorlog when first starting the new server (priv tables not upgraded of course)

061218 13:38:20 [ERROR] Column count of mysql.db is wrong. Expected 22, found 20. Table probably corrupted
061218 13:38:20 [ERROR] (db) Expected field Event_priv at position 20 to have type enum('N','Y')  but no field found.
061218 13:38:20 [ERROR] (db) Expected field Trigger_priv at position 21 to have type enum('N','Y')  but no field found.
061218 13:38:20 [ERROR] mysql.user has no `Event_priv` column at position 29
061218 13:38:20 [ERROR] SCHEDULER: The system tables are damaged. The scheduler subsystem will be unusable during this run.

===
Output from fix_mysql_privilege_tables --verbose

This script updates all the mysql privilege tables to be usable by
MySQL 5.1 and above.

You can safely ignore all 'Duplicate column' and 'Unknown column' errors
because these just mean that your tables are already up to date.
This script is safe to run even if your tables are already up to date!

ERROR 1060 (42S21) at line 28: Duplicate column name 'File_priv'
ERROR 1060 (42S21) at line 34: Duplicate column name 'Grant_priv'
ERROR 1060 (42S21) at line 35: Duplicate column name 'Grant_priv'
ERROR 1060 (42S21) at line 36: Duplicate column name 'Grant_priv'
ERROR 1060 (42S21) at line 47: Duplicate column name 'ssl_type'
ERROR 1060 (42S21) at line 76: Duplicate column name 'Routine_type'
ERROR 1054 (42S22) at line 100: Unknown column 'Type' in 'columns_priv'
ERROR 1060 (42S21) at line 106: Duplicate column name 'type'
ERROR 1060 (42S21) at line 116: Duplicate column name 'Show_db_priv'
ERROR 1060 (42S21) at line 132: Duplicate column name 'max_questions'
ERROR 1060 (42S21) at line 142: Duplicate column name 'Create_tmp_table_priv'
ERROR 1060 (42S21) at line 145: Duplicate column name 'Create_tmp_table_priv'
ERROR 1061 (42000) at line 150: Duplicate key name 'Grantor'
ERROR 1060 (42S21) at line 257: Duplicate column name 'Create_view_priv'
ERROR 1060 (42S21) at line 258: Duplicate column name 'Create_view_priv'
ERROR 1060 (42S21) at line 259: Duplicate column name 'Create_view_priv'
ERROR 1060 (42S21) at line 264: Duplicate column name 'Show_view_priv'
ERROR 1060 (42S21) at line 265: Duplicate column name 'Show_view_priv'
ERROR 1060 (42S21) at line 266: Duplicate column name 'Show_view_priv'
ERROR 1060 (42S21) at line 287: Duplicate column name 'Create_routine_priv'
ERROR 1060 (42S21) at line 288: Duplicate column name 'Create_routine_priv'
ERROR 1060 (42S21) at line 289: Duplicate column name 'Create_routine_priv'
ERROR 1060 (42S21) at line 294: Duplicate column name 'Alter_routine_priv'
ERROR 1060 (42S21) at line 295: Duplicate column name 'Alter_routine_priv'
ERROR 1060 (42S21) at line 296: Duplicate column name 'Alter_routine_priv'
ERROR 1060 (42S21) at line 298: Duplicate column name 'Execute_priv'
ERROR 1060 (42S21) at line 299: Duplicate column name 'Execute_priv'
ERROR 1060 (42S21) at line 311: Duplicate column name 'max_user_connections'
ERROR 1060 (42S21) at line 320: Duplicate column name 'Create_user_priv'
ERROR 1054 (42S22) at line 477: Unknown column 'specific_name' in 'proc'
ERROR 1054 (42S22) at line 523: Unknown column 'db' in 'proc'
ERROR 1307 (HY000) at line 535: Failed to CREATE PROCEDURE create_log_tables
ERROR 2013 (HY000) at line 564: Lost connection to MySQL server during query
ERROR 2006 (HY000) at line 565: MySQL server has gone away
ERROR 2006 (HY000) at line 571: MySQL server has gone away
ERROR 2006 (HY000) at line 633: MySQL server has gone away
ERROR 2006 (HY000) at line 634: MySQL server has gone away
ERROR 2006 (HY000) at line 636: MySQL server has gone away
ERROR 2006 (HY000) at line 637: MySQL server has gone away
ERROR 2006 (HY000) at line 638: MySQL server has gone away
ERROR 2006 (HY000) at line 639: MySQL server has gone away
ERROR 2006 (HY000) at line 640: MySQL server has gone away
ERROR 2006 (HY000) at line 673: MySQL server has gone away
ERROR 2006 (HY000) at line 674: MySQL server has gone away
ERROR 2006 (HY000) at line 680: MySQL server has gone away
ERROR 2006 (HY000) at line 681: MySQL server has gone away
ERROR 2006 (HY000) at line 683: MySQL server has gone away
ERROR 2006 (HY000) at line 684: MySQL server has gone away
ERROR 2006 (HY000) at line 685: MySQL server has gone away
ERROR 2006 (HY000) at line 686: MySQL server has gone away
ERROR 2006 (HY000) at line 688: MySQL server has gone away
ERROR 2006 (HY000) at line 690: MySQL server has gone away
ERROR 2006 (HY000) at line 696: MySQL server has gone away
done

The OSX x86 binary does not provide a backtrace. However, looking at the line numbers of the share/mysql_fix_privilege_tables.sql file (comparing with the above output and error messages) should indicate where the problem occurs.

How to repeat:
Update from 5.0.x to 5.1.14 (or simply copy the datadir across), start server, then run mysql_fix_privilege_tables --verbose. Stop/start server, verify in error log that the grant tables are still not correct. This will be due to the crash, the system never gets through the script.

Suggested fix:
Put various common upgrade paths in the testsuite: create certain mysql db structure (belonging with a specific version), run the upgrade script, check results (and of course crashes would be caught also).
[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