Heads up! MySQL 5.7 DMR6 contains a (small) known bug

MySQL 5.7 DMR6 was been released today! By my crude measurement, it is a big release with a number of new features and bug fixes:

morgo@Rbook:~$ for V in 1 2 3 4 5 6; do curl --silent http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-$V.html | wc -l; done;
4914 <-- DMR2
4121 <-- DMR6

The release notes have one important known bug to note:


This bug has been fixed in 5.7.7.

Published by


I joined MySQL AB in 2006, left, and am now back at Oracle working on the MySQL team. I've also worked at Percona and InPowered.

  • Justin Swanhart

    I find this highly inconvenient:
    "You cannot use mysqldump to dump the user table from a version of MySQL older than 5.7.6 and reload the dump file into MySQL 5.7.6 or later. Instead, perform a binary (in-place) upgrade to MySQL 5.7.6 or later and run mysql_upgrade to migrate the Password column contents to the authentication_string column."

    MySQL 5.7.6 should either:
    refuse to drop user unless FORCE option is used (mysql -f < mysqldump.sql would be needed, and 5.7 mysqldump would automatically drop user table with FORCE option.
    provide a utility to convert an incompatible mysqldump into a compatible one by transparently modifying the definition of the table and modifying the inserts. This isn't rocket science to make
    keeping the password column and set the hash column automatically when the password column is inserted into. Set password to null afterwards.

    The primary way to update from an old release (say 5.0) to a new release (say 5.7) is to dump and restore. This breaks that completely.

    • http://www.tocker.ca/ Morgan Tocker

      Thank you for the feedback. I will pass it along to the team!

    • Want communication and not onl