• The MySQL-shared-compat RPM package enables users of Red Hat-privided 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 libmysqlclient.so 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)

• Security Fix: Bug #59533 was fixed.

• Performance: Partitioning: InnoDB Storage Engine: 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 bug was introduced by Bug #11756867.

• Performance: InnoDB Storage Engine: Improved the performance of the DROP TABLE statement for InnoDB tables, especially on systems with a large buffer pool. The fix speeds up the processing for freeing entries in the adaptive hash index. (Bug #13704145, Bug #64284)

• InnoDB Storage Engine: Deleting a huge amount of data from InnoDB tables within a short time could cause the purge operation that flushes data from the buffer pool to stall. If this issue occurs, restart the server to work around it. This issue is only likely to occur on 32-bit platforms. (Bug #13847885)

• InnoDB Storage Engine: 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 Storage Engine: 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)

• Partitioning: After updating a row of a partitioned table and selecting that row within the same transaction with the query cache enabled, then performing a ROLLBACK, the same result was returned by an identical SELECT issued in a new transaction. (Bug #11761296, Bug #53775)

• 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, 0 is used as the default. This change also affects the default used 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)

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

To upgrade:

yum upgrade mysql

• InnoDB Storage Engine: A deprecation warning is now issued when --ignore-builtin-innodb is used. (Bug #13586262)

• yaSSL was upgraded from version 1.7.2 to 2.2.0.

• Important Change: InnoDB Storage Engine: When a row grew in size due to an UPDATE operation, other (non-updated) columns could be moved to off-page storage so that information about the row still fit within the constraints of the InnoDB page size. The pointer to the new allocated off-page data was not set up until the pages were allocated and written, potentially leading to lost data if the system crashed while the column was being moved out of the page. The problem was more common with tables using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED along with the Barracuda file format, particularly with the innodb_file_per_table setting enabled, because page allocation operations are more common as the .ibd tablespace files are extended. Still, the problem could occur with any combination of InnoDB version, file format, and row format.

  A related issue was that during such an UPDATE operation, or an INSERT operation that reused a delete-marked record, other transactions could see invalid data for the affected column, regardless of isolation level.

  The fix corrects the order of operations for moving the column data off the original page and replacing it with a pointer. Now if a crash occurs at the precise moment when the column data is being transferred, the transfer will not be re-run during crash recovery.

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

• InnoDB Storage Engine: An erroneous assertion could occur, in debug builds only, when creating an index on a column containing zero-length values (that is, ''). (Bug #13654923)

• InnoDB Storage Engine: A DDL operation such as ALTER TABLE ... ADD COLUMN could stall, eventually timing out with an Error 1005: Can't create table message referring to fil_rename_tablespace. (Bug #13636122, Bug #62100, Bug #63553)

• InnoDB Storage Engine: A DDL operation for an InnoDB table could cause a busy MySQL server to halt with an assertion error:

  InnoDB: Failing assertion: trx->error_state == DB_SUCCESS 

  The error occurred if the DDL operation was run while all 1023 undo slots were in use by concurrent transactions. This error was less likely to occur in MySQL 5.5 and 5.6, because raising the number of InnoDB undo slots increased the number of simultaneous transactions (corresponding to the number of undo slots) from 1K to 128K. (Bug #12739098, Bug #62401)

• InnoDB Storage Engine: Server startup could produce an error for temporary tables using the InnoDB storage engine, if the path in the $TMPDIR variable ended with a / character. The error log would look like:

  120202 19:21:26  InnoDB: Operating system error number 2 in a file operation. 
  InnoDB: The error means the system cannot find the path specified. 
  InnoDB: If you are installing InnoDB, remember that you must create 
  InnoDB: directories yourself, InnoDB does not create them. 
  120202 19:21:26  InnoDB: Error: trying to open a table, but could not 
  InnoDB: open the tablespace file './t/#sql7750_1_0.ibd'! 
  InnoDB: Have you moved InnoDB .ibd files around without using the 
  InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE? 
  InnoDB: It is also possible that this is a temporary table #sql..., 
  InnoDB: and MySQL removed the .ibd file for this. 

  The workaround for the problem was to create a similar temporary table again, copy its .frm file to tmpdir under the name mentioned in the error message (for example, #sql123.frm) and restart mysqld with tmpdir set to its normal value without a trailing slash, for example /var/tmp. On startup, MySQL would see the .frm file and issue DROP TABLE for the orphaned temporary table. (Bug #11754376, Bug #45976)

• Replication: Statements that wrote to tables with AUTO_INCREMENT columns based on an unordered SELECT from another table could lead to the master and the slave going out of sync, as the order in which the rows are retrieved from the table may differ between them. Such statements include any INSERT ... SELECT, REPLACE ... SELECT, or CREATE TABLE ... SELECT statement. Such statements are now marked as unsafe for statement-based replication, which causes the execution of one to throw a warning, and forces the statement to be logged using the row-based format if the logging format is MIXED. (Bug #11758263, Bug #50440)

• The contents of the shared and shared-compat RPM packages had been changed in versions 5.5.6 and 5.6.1 to avoid the overlap which they traditionally had (and still have in MySQL 5.0 and 5.1). However, the RPM meta information had not been changed in accordance, and so RPM still assumed a conflict between shared and shared-compat RPM packages. This has been fixed. (Bug #60855, Bug #12368215)

  References: See also Bug #56150.

• myisam_sort_buffer_size could not be set larger than 4GB on 64-bit systems. (Bug #45702, Bug #11754145)

• Due to improper locking, concurrent inserts into an ARCHIVE table at the same time as repair and check operations on the table resulted in table corruption. (Bug #37280, Bug #11748748)

To Upgrade:

yum upgrade mysql