MySQL 5.5.20

Title:

MySQL 5.5.20

File Size:

31.2 MB

Requirements:

Windows 9x / 2000 / XP / Vista / Windows7 / Windows8

Language:

en-us

License:

Open Source

Date Added:

12 Jan 2012

Publisher:

MySQL AB

Homepage:

http://www.mysql.com

MD5 Checksum:

65B27D1009FCD4B97CF835F1AD54F080

# Bugs Fixed
* Important Change: Replication: Setting an empty user in a CHANGE MASTER TO statement caused an invalid internal result and is no longer permitted. Trying to use MASTER_USER='' or setting MASTER_PASSWORD while leaving MASTER_USER unset causes the statement to fail with an error.
* Important Change: Replication: Moving the binary log file, relay log file, or both files to a new location, then restarting the server with a new value for --log-bin, --relay-log, or both, caused the server to abort on start. This was because the entries in the index file overrode the new location. In addition, paths were calculated relative to datadir (rather than to the --log-bin or --relay-log values). The fix for this problem means that, when the server reads an entry from the index file, it now checks whether the entry contains a relative path. If it does, the relative part of the path is replaced with the absolute path set using the --log-bin or --relay-log option. An absolute path remains unchanged; in such a case, the index must be edited manually to enable the new path or paths to be used.
* InnoDB Storage Engine: When doing a live downgrade from MySQL 5.6.4 or later, with innodb_page_size set to a value other than 16384, now the earlier MySQL version reports that the page size is incompatible with the older version, rather than crashing or displaying a “corruption” error.
* InnoDB Storage Engine: Issuing INSERT...ON DUPLICATE KEY statements for InnoDB tables from concurrent threads could cause a deadlock, particularly with the INSERT...ON DUPLICATE KEY UPDATE form. The fix avoids deadlocks caused by the same row being accessed by more than one transaction. Deadlocks could still occur when multiple rows are inserted and updated simultaneously by different transactions in inconsistent order; those types of deadlocks require the standard error handling on the application side, of re-trying the transaction.
* An incorrect InnoDB assertion could cause the server to halt. This issue only affected debug builds. The assertion referenced the source file btr0pcur.ic and the variable cursor->pos_state.
* Locale information for FORMAT() function instances was lost in view definitions.
* The handle_segfault() signal-handler code in mysqld could itself crash due to calling unsafe functions.
* Enabling myisam_use_mmap could cause the server to crash.
* Concurrent access to ARCHIVE tables could cause corruption.