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.34 (2013-09-20, General Availability)

Changes in MySQL 5.5.34 (2013-09-20, General Availability)

Audit Log Notes

  • MySQL 5.7 changed audit log file output to a new format that has better compatibility with Oracle Audit Vault. This format has been backported to MySQL 5.5 and it is possible to select either the old or new format using the new audit_log_format system variable, which has permitted values of OLD and NEW (default OLD). For details about each format, see Audit Log File Formats.

    In addition, when the audit log plugin rotates the audit log file, it uses a different file name format. For a log file named audit.log, the plugin previously renamed the file to audit.log.TIMESTAMP. The plugin now renames the file to audit.log.TIMESTAMP.xml to indicate that it is an XML file.

    If you change the value of audit_log_format, use this procedure to avoid writing log entries in one format to an existing log file that contains entries in a different format:

    1. Stop the server.

    2. Rename the current audit log file manually.

    3. Restart the server with the new value of audit_log_format. The audit log plugin will create a new log file, which will contain log entries in the selected format.

    The API for writing audit plugins has also changed. The mysql_event_general structure has new members to represent client host name and IP address, command class, and external user. For more information, see Writing Audit Plugins.

Bugs Fixed

  • InnoDB; Partitioning: Following any query on the INFORMATION_SCHEMA.PARTITIONS table, InnoDB index statistics as shown in the output of statements such as SELECT * FROM INFORMATION_SCHEMA.STATISTICS were read from the last partition, instead of from the partition containing the greatest number of rows. (Bug #11766851, Bug #60071)

    References: See also: Bug #16882435, Bug #69179.

  • InnoDB: The row_sel_sec_rec_is_for_clust_rec function would incorrectly prepare to compare a NULL column prefix in a secondary index with a non-NULL column in a clustered index. (Bug #17312846)

  • InnoDB: An incorrect purge would occur when rolling back an update to a delete-marked record. (Bug #17302896)

  • InnoDB: Adding a foreign key with a constraint name that included the string _ibfk_ caused InnoDB to create a duplicate constraint with a generated internal name. The generated internal name could also collide with an existing user-defined constraint of the same name, causing a duplicate key error. (Bug #17076737, Bug #69693, Bug #17076718, Bug #69707)

  • InnoDB: Rolling back an INSERT after a failed BLOB write would result in an assertion failure. The assertion has been modified to allow NULL BLOB pointers if an error occurs during a BLOB write. (Bug #16971045)

  • InnoDB: A regression introduced with the fix for Bug #11762038 would cause InnoDB to raise an incorrect error message. The message stated that, InnoDB cannot delete/update rows with cascading foreign key constraints that exceed max depth of 20. The error message would occur when killing connections reading from InnoDB tables that did not have foreign key constraints. (Bug #16710923)

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

  • InnoDB: The documentation incorrectly stated that START TRANSACTION WITH CONSISTENT SNAPSHOT provides a consistent snapshot only if the current isolation level is REPEATABLE READ or SERIALIZABLE. START TRANSACTION WITH CONSISTENT SNAPSHOT only works with REPEATABLE READ. All other isolation levels are ignored. The documentation has been revised and a warning is now generated whenever the WITH CONSISTENT SNAPSHOT clause is ignored. (Bug #14017206, Bug #65146)

  • InnoDB: The srv_master_thread background thread, which monitors server activity and performs activities such as page flushing when the server is inactive or in a shutdown state, runs on a one second delay loop. srv_master_thread failed to check if the server is in a shutdown state before sleeping. (Bug #13417564, Bug #63276)

  • InnoDB: An infinite loop could occur in buf_page_get_gen when handling compressed-only pages. (Bug #12560151, Bug #61132)

  • Partitioning: Creating a table t1 using CREATE TABLE ... PARTITION BY LIST ... PARTITION ... VALUES IN (NULL), then attempting to execute CREATE TABLE ... LIKE t1 caused the server to fail. (Bug #16860588)

  • Replication: A slave using row-based replication was unable to read the rows containing columns of type MYSQL_TYPE_DECIMAL properly (old-style decimal, used prior to MySQL 5.0.3). Now the slave throws an error if it receives this type of data. You can convert the old-style DECIMAL format to the binary format used in current MySQL releases with ALTER TABLE; see Upgrading from MySQL 4.1 to 5.0, for more information. (Bug #16416302)

  • Replication: DROP TEMP TABLE IF EXISTS statements could lead to failures in applying the binary log during point-in-time recovery operations. This is due to the fact that, when using row-based replication, the server appends IF EXISTS to any DROP TEMPORARY TABLE statements written to the binary log, and that the slave SQL thread does not check * wildcard filter rules for DROP TEMPORARY TABLE IF EXISTS. If --log-slave-updates was also enabled on the slave, such a statement was preceded by a USE statement. If the database referred by the USE statement did not exist, the statement failed, and stopped replication.

    Now, when writing DROP TEMPORARY TABLE IF EXISTS into the binary log, no USE statement is written, and the table name in the DROP TEMPORARY TABLE statement is a fully qualified table name. (Bug #16290902)

  • Savepoints could not be used successfully following an ER_LOCK_DEADLOCK error (or ER_LOCK_WAIT_TIMEOUT error, if innodb_rollback_on_timeout was enabled). (Bug #17356954)

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

  • Within a stored program, comparison of the value of a scalar subquery with an IN clause resulted in an error for the first execution and raised an assertion for the second execution. (Bug #17029399)

  • The my_strtoll10() function could incorrectly convert some long string-format numbers to numeric values and fail to set the overflow flag. (Bug #16997513)

  • A race condition in the thread pool plugin could cause status variables such as Aborted_connects not to be incremented and permitting concurrent kills to happen for the same thread ID. (Bug #16959022)

  • Within a stored procedure, repeated execution of a prepared CREATE TABLE statement for a table with partitions could cause a server exit. (Bug #16614004)

  • Deadlocks involving metadata locks and InnoDB deadlocks were both reported as an ER_LOCK_DEADLOCK error, but only InnoDB deadlocks rolled back the transaction. Now both deadlocks roll back the transaction. (Bug #14188793)

  • For queries that accessed an INFORMATION_SCHEMA table in a subquery, an attempt to lock a mutex that had already been locked could cause a server crash. (Bug #11765744)

  • RPM packages did not provide lowercase tags for their contents. For example, a server RPM indicated that it provided MySQL-server, but not mysql-server. (Bug #69830, Bug #17211588)

  • InnoDB deadlock caused transaction rollback but did not release metadata locks, blocking concurrent DDL on the transaction tables until the connection that got the deadlock issued an explicit COMMIT or ROLLBACK. (Bug #69668, Bug #17054007)

  • mysqldump wrote SET statements as SET OPTION, which failed when reloaded because the deprecated OPTION keyword has been removed from SET syntax. (Bug #67507, Bug #15844882)

  • For failure to create a new thread for the event scheduler, event execution, or new connection, no message was written to the error log. This could lead to the impression that the event scheduler was running normally when it was not. (Bug #67191, Bug #14749800, Bug #16865959)

  • If one connection changed its default database and simultaneously another connection executed SHOW PROCESSLIST, the second connection could access invalid memory when attempting to display the first connection's default database. memory. (Bug #58198, Bug #11765252)