Bug #35934 mysql_upgrade calls mysqlcheck with insufficient parameters
| Submitted: | 9 Apr 2008 12:25 | Modified: | 24 Feb 2009 20:42 |
|---|---|---|---|
| Reporter: | Philip Stoev | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Command-line Clients | Severity: | S2 (Serious) |
| Version: | 5.1 | OS: | Any |
| Assigned to: | Alexey Botchkov | CPU Architecture: | Any |
[9 Apr 2008 12:25]
Philip Stoev
[9 Apr 2008 15:47]
Sveta Smirnova
Thank you for the report. Verified as described.
[10 Apr 2008 18:59]
Omer Barnir
elated tobug#30654
[15 Jun 2008 14:23]
Alexey Botchkov
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/47878 2656 Alexey Botchkov 2008-06-15 Bug #35934 mysql_upgrade calls mysqlcheck with insufficient parameters.
[17 Jun 2008 14:52]
Chad MILLER
This is fine, IFF we can be sure that the mysqlcheck will be of the v5.1 server. Should it fail if it's from a version from before "fix-db-names" and "fix-table-names" was available? I think so.
[9 Dec 2008 9:48]
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/61015 2733 Alexey Botchkov 2008-12-09 Bug#35934 mysql_upgrade calls mysqlcheck with insufficient parameters modifying the original fix. As it turned out --fix-db-names option of the mysqlcheck suppress the --check_upgrade option, so we have to call the mysqlcheck twice from the mysql_upgrade. per-file comments: client/mysql_upgrade.c Bug#35934 mysql_upgrade calls mysqlcheck with insufficient parameters
[17 Dec 2008 22:50]
Alexander Rubin
It does not fix db names as well, not only table names
[15 Jan 2009 6:34]
Bugs System
Pushed into 5.1.31 (revid:joro@sun.com-20090115053147-tx1oapthnzgvs1ro) (version source revid:azundris@mysql.com-20081230114838-cn52tu180wcrvh0h) (merge vers: 5.1.31) (pib:6)
[19 Jan 2009 11:23]
Bugs System
Pushed into 5.1.31-ndb-6.2.17 (revid:tomas.ulin@sun.com-20090119095303-uwwvxiibtr38djii) (version source revid:tomas.ulin@sun.com-20090115073240-1wanl85vlvw2she1) (merge vers: 5.1.31-ndb-6.2.17) (pib:6)
[19 Jan 2009 13:00]
Bugs System
Pushed into 5.1.31-ndb-6.3.21 (revid:tomas.ulin@sun.com-20090119104956-guxz190n2kh31fxl) (version source revid:tomas.ulin@sun.com-20090119104956-guxz190n2kh31fxl) (merge vers: 5.1.31-ndb-6.3.21) (pib:6)
[19 Jan 2009 16:06]
Bugs System
Pushed into 5.1.31-ndb-6.4.1 (revid:tomas.ulin@sun.com-20090119144033-4aylstx5czzz88i5) (version source revid:tomas.ulin@sun.com-20090119144033-4aylstx5czzz88i5) (merge vers: 5.1.31-ndb-6.4.1) (pib:6)
[20 Jan 2009 18:58]
Bugs System
Pushed into 6.0.10-alpha (revid:joro@sun.com-20090119171328-2hemf2ndc1dxl0et) (version source revid:azundris@mysql.com-20081230114916-c290n83z25wkt6e4) (merge vers: 6.0.9-alpha) (pib:6)
[27 Jan 2009 21:20]
Alexander Rubin
The databases are still not fixed with upgrade. To fix the database names (if they contain "-" symbol for example) you will need to run: mysqlcheck --check-upgrade --fix-db-names --fix-table-names --all-databases
[5 Feb 2009 21:50]
Alexander Rubin
I have checked mysql 5.1.31 and now both databases and tables are fixed when running mysql_upgrade
[24 Feb 2009 20:42]
Paul DuBois
Noted in 5.1.31, 6.0.10 changelogs. For upgrades to MySQL 5.1 or higher, mysql_upgrade did not re-encode database or table names that contained non-alphanumeric characters. (They would still appear after the upgrade with the #mysql50# prefix described in http://dev.mysql.com/doc/refman/5.1/en/identifier-mapping.html.) To correct this problem, it was necessary to run mysqlcheck --all-databases --check-upgrade --fix-db-names --fix-table-names manually. mysql_upgrade now runs that command automatically after performing the initial upgrade.
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.074 sec. using MySQL 8.4.7-u6-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.