Skip navigation links
MySQL 5.5 Release Notes :: Changes in MySQL 5.5.11 (2011-04-07)
Changes in MySQL 5.5.10 (2011-03-15) »
Section Navigation      [Toggle]

Changes in MySQL 5.5.11 (2011-04-07)

Functionality Added or Changed

  • InnoDB now permits concurrent reads on a table while creating nonprimary unique indexes. (This was found to create problems and was reverted in 5.5.12.) (Bug #11784056)

  • MySQL distributions now include an INFO_SRC file that contains information about the source distribution, such as the MySQL version from which it was created. MySQL binary distributions additionally include an INFO_BIN file that contains information about how the distribution was built, such as compiler options and feature flags. In RPM packages, these files are located in the /usr/share/doc/packages/MySQL-server directory. In tar.gz and derived packages, they are located in the Docs directory under the location where the distribution is unpacked. (Bug #42969, Bug #11751935)

  • Previously, Performance Schema instrumentation for both the binary log and the relay log used these instruments: 

    wait/io/file/sql/binlog 
wait/io/file/sql/binlog_index 
wait/synch/mutex/sql/MYSQL_BIN_LOG::LOCK_index 
wait/synch/cond/sql/MYSQL_BIN_LOG::update_cond

    Now instrumentation for the relay log uses these instruments, which makes it possible to distinguish binary log and relay log events: 

    wait/io/file/sql/relaylog 
wait/io/file/sql/relaylog_index 
wait/synch/mutex/sql/MYSQL_RELAY_LOG::LOCK_index 
wait/synch/cond/sql/MYSQL_RELAY_LOG::update_cond

    (Bug #59658, Bug #11766528)

  • Previously, for queries that were aborted due to a sort problem or terminated with KILL in the middle of a sort, the server wrote the message Sort aborted to the error log. Now the server writes more information about the cause of the error. These causes include:

    • Insufficient disk space in the temporary file directory prevented a temp file from being created

    • Insufficient memory for sort_buffer_size to be allocated

    • Somebody ran KILL id in the middle of a filesort operation

    • The server was shut down while some queries were sorting

    • A transaction was rolled back or aborted due to a lock wait timeout or deadlock

    • Unexpected errors, such as a source table or even temp table was corrupt

    • Processing of a subquery failed which was also sorting

    (Bug #30771, Bug #11747102)

  • The undocumented SHOW NEW MASTER statement has been removed.

  • For the Windows installer, debug information files and the embedded MySQL server have been removed from the standard MSI distribution file to reduce the download size for the majority of users.

    If these files are needed, the Zip distribution must be downloaded separately and be extracted in the installation directory, which is most probably C:\Program Files\MySQL\MySQL Server 5.5 on English systems.

    Please note that upon product de-installation, these extracted files from the Zip distribution must be removed from the system manually.

  • A new system variable, max_long_data_size, now controls the maximum size of parameter values that can be sent with the mysql_stmt_send_long_data() C API function. If not set at server startup, the default is the value of the max_allowed_packet system variable. This variable is deprecated. In MySQL 5.6, it is removed and the maximum parameter size is controlled by max_allowed_packet.

Bugs Fixed

  • Important Change: The length of the plugin column of the mysql.user system table is increased to 64 characters. This is now the same size as the name column of the mysql.plugin table. (Bug #11766610, Bug #59752)

  • Partitioning: A problem with a previous fix for poor performance of INSERT ON DUPLICATE KEY UPDATE statements on tables having many partitions caused the handler function for reading a row from a specific index to fail to store the ID of the partition last used. This caused some statements to fail with Can't find record errors. (Bug #59297, Bug #11766232)

    References: This bug is a regression of Bug #52455.

  • Replication: A failed DROP DATABASE statement could break statement-based replication. (Bug #58381, Bug #11765416)

  • Two unused test files in storage/ndb/test/sql contained incorrect versions of the GNU Lesser General Public License. The files and the directory containing them have been removed. (Bug #11810224)

    References: See also Bug #11810156.

  • Division of large numbers could cause stack corruption. (Bug #11792200)

  • The server read one byte too many when trying to process an XML string lacking a closing single quote (') or double quote (") character used as an argument for UpdateXML() or ExtractValue(). (Bug #59901, Bug #11766725)

    References: See also Bug #44332, Bug #11752979.

  • Aggregation followed by a subquery could produce an incorrect result. (Bug #59839, Bug #11766675)

  • mysqldump did not quote database names in ALTER DATABASE statements in its output, which could cause an error at reload time for database names containing a dash. (Bug #59398, Bug #11766310)

  • On some systems, debug builds of comp_err could fail due to an uninitialized variable. (Bug #59906, Bug #11766729)

  • If a multiple-table update updated a row through two aliases and the first update physically moved the row, the second update failed to locate the row. This resulted in different errors depending on the storage engine, although these errors did not accurately describe the problem:

    • MyISAM: Got error 134 from storage engine

    • InnoDB: Can't find record in 'tbl'

    For MyISAM, which is nontransactional, the update executed first was performed but the second was not. In addition, for two equal multiple-table update statements, one could succeed and the other fail depending on whether the record actually moved, which is inconsistent.

    Now such an update returns an error if it will update a table through multiple aliases, and perform an update that may physically move the row in at least one of these aliases. (Bug #57373, Bug #11764529, Bug #55385, Bug #11762751)

  • SHOW WARNINGS output following EXPLAIN EXTENDED could include unprintable characters. (Bug #57341, Bug #11764503)

  • Bitmap functions used in one thread could change bitmaps used by other threads, raising an assertion. (Bug #43152, Bug #11752069)

  • Attempting to create a spatial index on a CHAR column longer than 31 bytes led to an assertion failure if the server was compiled with safemutex support. (Bug #59888, Bug #11766714)

  • An assertion was raised if an XA COMMIT was issued when an XA transaction had already encountered an error (such as a deadlock) that required the transaction to be rolled back. (Bug #59986, Bug #11766788)

  • The MYSQL_HOME environment variable was being ignored. (Bug #59280, Bug #11766219)

  • When CASE ... WHEN arguments had different character sets, 8-bit values could be referenced as utf16 or utf32 values, raising an assertion. (Bug #44793, Bug #11753363)

  • An incorrect character set pointer passed to my_strtoll10_mb2() caused an assertion to be raised. (Bug #59648, Bug #11766519)

  • An assertion was raised if a statement tried to upgrade a metadata lock while there was an active FLUSH TABLE tbl_list WITH READ LOCK statement. Now if a statement tries to upgrade a metadata lock in this situation, the server returns an ER_TABLE_NOT_LOCKED_FOR_WRITE error to the client. (Bug #57649, Bug #11764779)

  • The code for PROCEDURE ANALYSE() had a missing DBUG_RETURN statement, which could cause a server crash in debug builds. (Bug #58140, Bug #11765202)

  • For a client connected using SSL, the Ssl_cipher_list status variable was empty and did not show the possible cipher types. (Bug #52596, Bug #11760210)

  • When used to upgrade tables, mysqlcheck (and mysql_upgrade, which invokes mysqlcheck) did not upgrade some tables for which table repair was found to be necessary. In particular, it failed to upgrade InnoDB tables that needed repair, leaving them in a nonupgraded state. This occurred because:

    • mysqlcheck --check-upgrade ---auto-repair checks for tables that are incompatible with the current version of MySQL. It does this by issuing the CHECK TABLE ... FOR UPGRADE statement and examining the result.

    • For any table found to be incompatible, mysqlcheck issues a REPAIR TABLE statement. But this fails for storage engines such as InnoDB that do not support the repair operation. Consequently, the table remained unchanged.

    To fix the problem, the following changes were made to CHECK TABLE ... FOR UPGRADE and mysqlcheck. Because mysql_upgrade invokes mysqlcheck, these changes also fix the problem for mysql_upgrade.

    • CHECK TABLE ... FOR UPGRADE returns a different error if a table needs repair but its storage engine does not support REPAIR TABLE:

      Previous: 

      Error: ER_TABLE_NEEDS_UPGRADE
Table upgrade required. Please do "REPAIR TABLE `tbl_name`" or
dump/reload to fix it!

      Error: ER_TABLE_NEEDS_REBUILD
Table rebuild required. Please do "ALTER TABLE `tbl_name` FORCE" or
dump/reload to fix it!

    • mysqlcheck recognizes the new error and issues an ALTER TABLE ... FORCE statement. The FORCE option for ALTER TABLE was recognized but did nothing; now it is implemented and acts as a “null” alter operation that rebuilds the table.

    (Bug #47205, Bug #11755431)

  • CREATE TRIGGER and DROP TRIGGER can change the prelocking list of stored routines, but the routine cache did not detect such changes, resulting in routine execution with an inaccurate locking list. (Bug #58674, Bug #11765684)

  • On Windows, the authentication_string column recently added to the mysql.user table caused the Configuration Wizard to fail. (Bug #59038, Bug #11766011)

  • The mysql_load_plugin() C API function did not clear the previous error. (Bug #60075, Bug #11766854)

  • An invalid pathname argument for the --defaults-extra-file option of MySQL programs caused a program crash. (Bug #59234, Bug #11766184)

  • FIND_IN_SET() could work differently in MySQL 5.5 than in 5.1. (Bug #59405, Bug #11766317)

  • In some cases, SHOW WARNINGS returned an empty result when the previous statement failed. (Bug #55847, Bug #11763166)

  • On Windows, an object in thread local storage could be used before the object was created. (Bug #55730, Bug #11763065)

Copyright © 1997, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices