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.23 (2012-04-12, General Availability)

Changes in MySQL 5.5.23 (2012-04-12, General Availability)

Functionality Added or Changed

  • The MySQL-shared-compat RPM package enables users of Red Hat-provided mysql-*-5.1 RPM packages to migrate to Oracle-provided MySQL-*-5.5 packages. MySQL-shared-compat now replaces the Red Hat mysql-libs package by replacing files of the latter package, thus satisfying dependencies of other packages on mysql-libs. This change affects only users of Red Hat (or Red Hat-compatible) RPM packages. Nothing is different for users of Oracle RPM packages. (Bug #13867506)

Bugs Fixed

  • Security Fix: A security bug was fixed. (Bug #59533)

  • Important Change; Partitioning: The query cache did not always function correctly with partitioned tables in a transactional context. For this reason, the query cache is now disabled for any queries using partitioned tables, and such queries can no longer be cached. For more information, see Restrictions and Limitations on Partitioning. (Bug #11761296, Bug #53775)

  • Performance; InnoDB; Partitioning: The statistics used by the optimizer for queries against partitioned InnoDB tables were based only on the first partition of each such table, leading to use of the wrong execution plan. (Bug #13694811)

    References: This issue is a regression of: Bug #11756867.

  • Performance; InnoDB: This fix improves the speed of DROP TABLE for InnoDB tables by removing a scan of the buffer pool to remove entries for the adaptive hash index. This improvement is most noticeable on systems with very large buffer pools and the innodb_adaptive_hash_index option enabled. (Bug #13704145, Bug #64284)

  • InnoDB: The performance_schema counters for InnoDB RW-locks did not record some cases where mini-transactions acquired locks. (Bug #13860722)

  • InnoDB: Deleting a huge amount of data from InnoDB tables within a short time could cause the purge operation that removes delete-marked records to stall. This issue could result in unnecessary disk space use, but does not cause any problems with data integrity. If this issue causes a disk space shortage, restart the server to work around it. This issue is only likely to occur on 32-bit platforms. (Bug #13847885)

  • InnoDB: Running concurrent bulk inserts on a server with auto_increment_offset=1, auto_increment_increment greater than 1, and innodb_autoinc_lock_mode=1 could result in intermittent errors like the following, even with the primary key set to auto_increment and omitted from the INSERT statement:

    Duplicate entry 'value' for key 'PRIMARY'

    The workaround was to set auto_increment_offset=1 or innodb_autoinc_lock_mode=0 (traditional). (Bug #13817703, Bug #61209)

  • InnoDB: If the server crashed during a TRUNCATE TABLE or CREATE INDEX statement for an InnoDB table, or a DROP DATABASE statement for a database containing InnoDB tables, an index could be corrupted, causing an error message when accessing the table after restart:

    InnoDB: Error: trying to load index index_name for table table_name
    InnoDB: but the index tree has been freed!

    In MySQL 5.1, this fix applies to the InnoDB Plugin, but not the built-in InnoDB storage engine. (Bug #12861864, Bug #11766019)

  • InnoDB: When data was removed from an InnoDB table, newly inserted data might not reuse the freed disk blocks, leading to an unexpected size increase for the system tablespace or .ibd file (depending on the setting of innodb_file_per_table. The OPTIMIZE TABLE could compact a .ibd file in some cases but not others. The freed disk blocks would eventually be reused as additional data was inserted. (Bug #11766634, Bug #59783)

  • InnoDB: When shutting down the MySQL server, the cleanup operations of the InnoDB shutdown could take a long time with no output, making the server appear to be hung.

    [Note] mysqld: Normal shutdown
    InnoDB: Starting shutdown...
    InnoDB: Shutdown completed; log sequence number ...

    Now additional progress messages are displayed between the starting and completed messages:

    InnoDB: Waiting for srv_monitor_thread (srv_lock_timeout_thread/ srv_error_monitor_thread) to exit
    InnoDB: Waiting for %lu active transactions to exit
    InnoDB: Waiting for master thread (worker threads) to be suspended
    InnoDB: Pending checkpoint_writes: %lu
    InnoDB: Pending log flush writes: %lu
    InnoDB: Waiting for %lu buffer page I/Os to complete
    InnoDB: Waiting for dirty buffer pages to be flushed

    For both fast shutdown and slow shutdown, a progress messages is printed every 60 seconds:

    InnoDB: Waiting for %lu tables to be dropped

    During a slow shutdown, two additional messages are printed if certain phases take longer than normal:

    InnoDB: Waiting for %lu undo logs to be purged
    InnoDB: number of pages just purged: %lu
    InnoDB: Waiting for change buffer merge to complete\n
    InnoDB: number of bytes of change buffer just merged:  %lu

    (Bug #11755873, Bug #47707)

  • InnoDB: Fast index creation in the InnoDB Plugin could fail, leaving the new secondary index corrupted. (Bug #54330)

  • Replication: Formerly, the default value shown for the Port column in the output of SHOW SLAVE HOSTS was 3306 whether the port had been set incorrectly or not set at all. Now, when the slave port is not set, the actual port used by the slave is shown. This change also affects the default shown for the --report-port server option. (Bug #13333431)

  • Replication: The --relay-log-space-limit option was sometimes ignored.

    More specifically, when the SQL thread went to sleep, it allowed the I/O thread to queue additional events in such a way that the relay log space limit was bypassed, and the number of events in the queue could grow well past the point where the relay logs needed to be rotated. Now in such cases, the SQL thread checks to see whether the I/O thread should rotate and provide the SQL thread a chance to purge the logs (thus freeing space).

    Note that, when the SQL thread is in the middle of a transaction, it cannot purge the logs; it can only ask for more events until the transaction is complete. Once the transaction is finished, the SQL thread can immediately instruct the I/O thread to rotate. (Bug #12400313, Bug #64503)

    References: See also: Bug #13806492.

  • An infinite thread loop could develop within Performance Schema, causing the server to become unresponsive. (Bug #13898343)

  • Incorrect stored program caching could cause statements within a stored program that included a GROUP BY clause to return different results across multiple program invocations. (Bug #13805127)

  • Mishandling of NO_BACKSLASH_ESCAPES SQL mode within stored procedures on slave servers could cause replication failures. (Bug #12601974)

  • SAVEPOINT statements were incorrectly disallowed within XA transactions. (Bug #64374, Bug #13737343)

    References: See also: Bug #11766752.

  • The Performance Schema incorrectly displayed some backslashes in Windows file names (by doubling them). (Bug #63339, Bug #13417446)

  • On OS X 10.5, the MySQL Preference Pane did not run on Intel-based systems. (Bug #60712, Bug #13788147)

  • SHOW statements treated stored procedure, stored function, and event names as case sensitive. (Bug #56224, Bug #11763507)