Documentation Home
MySQL 5.5 Release Notes
Related Documentation Download these Release Notes
PDF (US Ltr) - 1.7Mb
PDF (A4) - 1.7Mb

MySQL 5.5 Release Notes  /  Changes in MySQL 5.5.19 (2011-12-08, General Availability)

Changes in MySQL 5.5.19 (2011-12-08, General Availability)

Functionality Added or Changed

  • Replication: Previously, replication slaves could connect to the master server through master accounts that use nonnative authentication, except Windows native authentication. This is now also true for Windows native authentication.

  • Performance of metadata locking operations on Windows XP systems was improved by instituting a cache for metadata lock objects. This permits the server to avoid expensive operations for creation and destruction of synchronization objects on XP. A new system variable, metadata_locks_cache_size, permits control over the size of the cache. The default size is 1024. (Bug #12695572)

Bugs Fixed

  • Important Change; InnoDB: If an ALTER TABLE statement failed for an InnoDB table due to an error code from an underlying file-renaming system call, InnoDB could lose track of the .ibd file for the table. This issue only occurred when the innodb_file_per_table configuration option was enabled, and when the low-level error persisted through thousands of retry attempts. In MySQL 5.1, this issue applied to the InnoDB Plugin but not the built-in InnoDB storage engine.

    For example, if you encounter an error like the following:

    mysql> ALTER TABLE sb2 ADD COLUMN d2 INT;
    ERROR 1025 (HY000): Error on rename of './sbtest/#sql-1eb9_1' to
    './sbtest/sb2' (errno: -1)

    you might be able to access the #sql* table by copying an .frm file from a table with an identical schema. The table name to use for the .frm filewould be `sbtest.#mysql50##sql-1eb9_1` in the preceding example. (Bug #12884631, Bug #62146)

  • InnoDB: An internal deadlock could occur within InnoDB, on a server doing a substantial amount of change buffering for DML operations, particularly DELETE statements. (Bug #13340047)

  • Replication: When a statement containing a large number of rows to be applied on a slave table that does not contain a primary key, a considerable amount of time can be needed to find and change all the rows that are to be changed. The current fix helps diagnose this issue by printing a message to the error log if the execution time for a given statement replicated using row-based replication takes more than 60 seconds. log_warnings must be greater than 1 for this message to be printed to the error log. (Bug #11760927, Bug #53375)

  • Rounding DBL_MAX returned DBL_MAX, not 'inf'. (Bug #13261955)

  • Writes to MyISAM temporary tables could include uninitialized data, which could contain sensitive information. Now only bytes containing initialized data are copied, which also improves performance. (Bug #12997905)

  • mysql_upgrade did not upgrade the system tables or create the mysql_upgrade_info file when run with the --write-binlog or --skip-write-binlog option. (Bug #60223, Bug #11827359)

  • If a plugin was uninstalled, thread local variables for plugin variables of string type with wth PLUGIN_VAR_MEMALLOC flag were not freed. (Bug #56652, Bug #11763882)

  • Deadlock could occur when these four things happened at the same time: 1) An old dump thread was waiting for the binary log to grow. 2) The slave server that replicates from the old dump thread tried to reconnect. During reconnection, the new dump thread tried to kill the old dump thread. 3) A KILL statement tried to kill the old dump thread. 4) An INSERT statement caused a binary log rotation. (Bug #56299, Bug #11763573)