MySQL releases are now built on all platforms using CMake rather than the GNU autotools, so autotools support has been removed. For instructions on building MySQL with CMake, see Section 2.11, “Installing MySQL from Source”. Third-party tools that need to extract the MySQL version number formerly found in configure.in can use the VERSION file. See Section 2.11.6, “MySQL Configuration and Third-Party Tools”.

Support for the IBMDB2I storage engine has been removed. (Bug#58079)

A --bind-address option has been added to a number of MySQL client programs: mysql, mysqldump, mysqladmin, mysqlbinlog, mysqlcheck, mysqlimport, and mysqlshow. This is for use on a computer having multiple network interfaces, and enables you to choose which interface is used to connect to the MySQL server.

Performance: InnoDB Storage Engine: Improved concurrency when several ANALYZE TABLE or SHOW TABLE STATUS statements are run simultaneously for InnoDB tables. (Bug#53046)

Incompatible Change: Previously, tables in the performance_schema database had uppercase names. This was incompatible with the lower_case_table_names system variable, and caused issues when the variable value was changed after installing or upgrading.

Now performance_schema table names are lowercase, so they appear in uniform lettercase regardless of the lower_case_table_names setting. References to these tables in SQL statements should be given in lowercase. This is an incompatible change, but provides compatible behavior across different values of lower_case_table_names.

If you upgrade to MySQL 5.5.8 from an earlier version of MySQL 5.5, be sure to run mysql_upgrade (and restart the server) to change the names of existing performance_schema tables from uppercase to lowercase. (Bug#57609)

Incompatible Change: The following changes were made to the performance_schema.threads table for conformance with the implementation in MySQL 5.6:

(Bug#57154)

Incompatible Change: Deadlock occurred when a connection that had some table open through a HANDLER statement tried to update data through a DML statement while another connection tried to execute FLUSH TABLES WITH READ LOCK concurrently. Starvation of FLUSH TABLES WITH READ LOCK statements occurred when there was a constant load of concurrent DML statements in two or more connections.

These problems resulted from the global read lock implementation, which was reimplemented with the following consequences:

(Bug#57006, Bug#54673)

InnoDB Storage Engine: Values could be truncated in certain INFORMATION_SCHEMA columns, such as REFERENTIAL_CONSTRAINTS.REFERENCED_TABLE_NAME and KEY_COLUMN_USAGE.REFERENCED_TABLE_NAME. (Bug#57960)

InnoDB Storage Engine: For an InnoDB table created with ROW_FORMAT=COMPRESSED or ROW_FORMAT=DYNAMIC, a query using the READ UNCOMMITTED isolation level could cause the server to stop with an assertion error, if BLOB or other large columns that use off-page storage were being inserted at the same time. (Bug#57799)

InnoDB Storage Engine: The server could stop with an assertion error on Windows Vista and Windows 7 systems. (Bug#57720)

InnoDB Storage Engine: A followup fix to Bug#54678. TRUNCATE TABLE could still cause a crash (assertion error) in the debug version of the server. (Bug#57700)

InnoDB Storage Engine: The InnoDB system tablespace could grow continually for a server under heavy load. (Bug#57611)

InnoDB Storage Engine: Heavy concurrent updates of a BLOB column in an InnoDB table could cause a hang. (Bug#57579)

InnoDB Storage Engine: The innodb_stats_on_metadata option could prevent the ANALYZE TABLE statement from running. (Bug#57252)

InnoDB Storage Engine: A query for an InnoDB table could return the wrong value if a column value was changed to a different case, and the column had a case-insensitive index. (Bug#56680)

InnoDB Storage Engine: An existing InnoDB could be switched to ROW_FORMAT=COMPRESSED implicitly by a KEY_BLOCK_SIZE clause in an ALTER TABLE statement. Now, the row format is only switched to compressed if there is an explicit ROW_FORMAT=COMPRESSED clause. on the ALTER TABLE statement.

Any valid, non-default ROW_FORMAT parameter takes precedence over KEY_BLOCK_SIZE when both are specified. KEY_BLOCK_SIZE only enables ROW_FORMAT=COMPRESSED if ROW_FORMAT is not specified on either the CREATE TABLE or ALTER TABLE statement, or is specified as DEFAULT. In case of a conflict between KEY_BLOCK_SIZE and ROW_FORMAT clauses, the KEY_BLOCK_SIZE is ignored if innodb_strict_mode is off, and the statement causes an error if innodb_strict_mode is on. (Bug#56632)

InnoDB Storage Engine: The clause KEY_BLOCK_SIZE=0 is now allowed on CREATE TABLE and ALTER TABLE statements for InnoDB tables, regardless of the setting of innodb_strict_mode. The zero value has the effect of resetting the KEY_BLOCK_SIZE table parameter to its default value, depending on the ROW_FORMAT parameter, as if it had not been specified. That default is 8 if ROW_FORMAT=COMPRESSED. Otherwise, KEY_BLOCK_SIZE is not used or stored with the table parameters.

As a consequence of this fix, ROW_FORMAT=FIXED is not allowed when the innodb_strict_mode is enabled. (Bug#56628)

InnoDB Storage Engine: A large number of foreign key declarations could cause the output of the SHOW CREATE STATEMENT statement to be truncated. (Bug#56143)

InnoDB Storage Engine: A compilation problem affected the InnoDB source code on NetBSD/sparc64. (Bug#53916)

InnoDB Storage Engine: Clarified the message when a CREATE TABLE statement fails because a foreign key constraint does not have the required indexes. (Bug#16290)

Partitioning: “Fast” ALTER TABLE operations (that do not involve a table copy) on a partitioned table could leave the table in an unusable state. (Bug#57985)

Partitioning: An INSERT ... ON DUPLICATE KEY UPDATE column = 0 statement on an AUTO_INCREMENT column caused the debug server to crash. (Bug#57890)

Replication: Concurrent statements using a stored function and a DROP DATABASE statement that caused the same stored function to be dropped could cause statement-based replication to fail. This problem is resolved by making sure that DROP DATABASE takes an exclusive metadata lock on all stored functions and stored procedures that it causes to be dropped. (Bug#57663)

See also Bug#30977.

Replication: When STOP SLAVE is issued, the slave SQL thread rolls back the current transaction and stops immediately if the transaction updates only tables which use transactional storage engines are updated. Previously, this occurred even when the transaction contained CREATE TEMPORARY TABLE statements, DROP TEMPORARY TABLE statements, or both, although these statements cannot be rolled back. Because temporary tables persist for the lifetime of a user session (in the case, the replication user), they remain until the slave is stopped or reset. When the transaction is restarted following a subsequent START SLAVE statement, the SQL thread aborts with an error that a temporary table to be created (or dropped) already exists (or does not exist, in the latter case).

Following this fix, if an ongoing transaction contains CREATE TEMPORARY TABLE statements, DROP TEMPORARY TABLE statements, or both, the SQL thread now waits until the transaction ends, then stops. (Bug#56118)

Replication: If there exist both a temporary table and a non-temporary table having the same, updates normally apply only to the temporary table, with the exception of a CREATE TABLE ... SELECT statement that creates a non-temporary table having the same name as an existing temporary table. When such a statement was replicated using the MIXED logging format, and the statement was unsafe for row-based logging, updates were misapplied to the temporary table.

Updates were also applied wrongly when a temporary table that used a transactional storage engine was dropped inside a transaction, followed by updates within the same transaction to a non-temporary table having the same name. (Bug#55478)

See also Bug#47899, Bug#55709.

Replication: When making changes to relay log settings using CHANGE MASTER TO, the I/O cache was not cleared. This could result in replication failure when the slave attempted to read stale data from the cache and then stopped with an assertion. (Bug#55263)

Replication: Replication of SET and ENUM columns represented using more than 1 byte (that is, SET columns with more than 8 members and ENUM columns with more than 256 constants) between platforms using different endianness failed when using the row-based format. This was because columns of these types are represented internally using integers, but the internal functions used by MySQL to handle them treated them as strings. (Bug#52131)

See also Bug#53528.

Replication: Trying to read from a binary log containing a log event of an invalid type caused the slave to crash. (Bug#38718)

Replication: When replicating the mysql.tables_priv table, the Grantor column was not replicated, and was thus left empty on the slave. (Bug#27606)

Setting the read_only system variable at server startup did not work. (Bug#58669)

mysql_upgrade failed after an upgrade from MySQL 5.1. (Bug#58514)

When configuring the build with -DBUILD_CONFIG=mysql_release and building with Visual Studio Express, the build failed if signtool.exe was not present. (Bug#58313)

When configuring the build with -DBUILD_CONFIG=mysql_release on Linux, libaio is required, but the error message if it was missing was uninformative. (Bug#58227)

Use of NAME_CONST() in a HAVING clause caused a server crash. (Bug#58199)

BETWEEN did not use indexes for DATE or DATETIME columns. (Bug#58190)

Memory was allocated in fn_expand() for storing path names, but not freed anywhere. (Bug#58173)

In debug builds, inserting a FLOAT value into a CHAR(0) column could crash the server. (Bug#58137)

Failure to create a thread to handle a user connection could result in a server crash. (Bug#58080)

During configuration, ADD_VERSION_INFO in cmake/mysql_version.cmake failed if LINK_FLAGS was modified. (Bug#58074)

Performance Schema did not account for I/O for the binary log file (no I/O was counted). (Bug#58052)

Several compilation problems were fixed. (Bug#57992, Bug#57993, Bug#57994, Bug#57995, Bug#57996, Bug#57997, Bug#58057)

After creating a table with two foreign key constraints, the INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS table displayed only one of them. (Bug#57904)

Incorrect error handling raised an assertion if character set conversion wrapped an item that failed. (Bug#57882)

In debug builds, a missing DBUG_RETURN macro in sql/client.c caused mysql to be unable to connect to the server. (Bug#57744)

Clients using a client library older than MySQL 5.5.7 suffered loss of connection after executing mysql_change_user() while connected to a 5.5.7 server. (Bug#57689)

The MySQL-shared RPM package failed to provide the lowercase virtual identifier 'mysql-shared' in the RPM 'Provides' tags (usually used for backward compatibility). (Bug#57596)

For an upgrade to MySQL 5.5.7 from a previous release, the server exited if the mysql.proxies_priv table did not exist, making upgrades inconvenient. Now the server treats a missing proxies_priv table as equivalent to an empty table. However, after starting the server, you should still run mysql_upgrade to create the table. (Bug#57551)

SHOW PROCESSLIST displayed non-ASCII characters improperly. (Bug#57306)

Passing a string that was not null-terminated to UpdateXML() or ExtractValue() caused the server to fail with an assertion. (Bug#57279)

SET GLOBAL debug could cause a crash on Solaris if the server failed to open the trace file. (Bug#57274)

In debug builds, an assertion could be raised during conversion of strings to floating-point values. (Bug#57203)

A user with no privileges on a stored routine or the mysql.proc table could discover the routine's existence. (Bug#57061)

Queries executed using the Index Merge access method and a temporary file could return incorrect results. (Bug#56862)

The server could crash as a result of accessing freed memory when populating INFORMATION_SCHEMA.VIEWS if a view could not be opened properly. (Bug#56540)

Valgrind warnings about overlapping memory when double-assigning the same variable were corrected. (Bug#56138)

If a STOP SLAVE statement was issued while the slave SQL thread was executing a statement that invoked the SLEEP() function, both statements hung. (Bug#56096)

OPTIMIZE TABLE for InnoDB tables could raise an assertion. (Bug#55930)

Warnings raised by a trigger were not cleared upon successful completion. Now warnings are cleared if the trigger completes successfully, per the SQL standard. (Bug#55850)

For CMake builds, some parts of the source were unnecessarily compiled twice if the embedded server was built. (Bug#55647)

Boolean command options caused an error if given with an option value and the loose- option prefix. (Bug#54569)

An error in a stored procedure could leave the session in a different default database. (Bug#54375)

The CMake “wrapper” for configure (configure.pl) did not handle the --with-comment option properly. (Bug#52275)

Grouping by a TIME_TO_SEC() function result could cause a server crash or incorrect results. Grouping by a function returning a BLOB could cause an unexpected “Duplicate entry” error and incorrect result. (Bug#52160)

The find_files() function used by SHOW statements performed redundant and unnecessary memory allocation. (Bug#51208)

The Windows sample option files contained values more appropriate for Linux. (Bug#50021)

A failed RENAME TABLE operation could prevent a FLUSH TABLES WITH READ LOCK from completing. (Bug#47924)

Error messages for several delegate-related initialization error conditions that should not occur were changed to help identify the area of failure and to instruct the user to file a bug report if they do occur. A delegate is a set of internal data structures and algorithms. (Bug#47027)

On file systems with case insensitive file names, and lower_case_table_names=2, the server could crash due to a table definition cache inconsistency. (Bug#46941)

Handling of host name lettercase in GRANT statements was inconsistent. (Bug#36742)

SET NAMES utf8 COLLATE utf8_sinhala_ci did not work. (Bug#26474)

The utf16_bin collation uses code-point order, not byte-by-byte order, as described at Section 9.1.14.1, “Unicode Character Sets”. (The order was byte-by-byte in MySQL 5.5.7.)

MySQL authentication supports two new capabilities, pluggable authentication and proxy users:

Pluggable authentication entails these changes:

Proxy user capability entails these changes:

Due to these changes, the server requires that a new grant table, proxies_priv, be present in the mysql database. If you are upgrading to MySQL 5.5.7 from a previous MySQL release rather than performing a new installation, the server will find that this table is missing and exit during startup with the following message:

Table 'mysql.proxies_priv' doesn't exist

To create the proxies_priv table, start the server with the --skip-grant-tables option to cause it to skip the normal grant table checks, then run mysql_upgrade. For example:

shell> mysqld --skip-grant-tables &
shell> mysql_upgrade

Then stop the server and restart it normally.

You can specify other options on the mysqld command line if necessary. Alternatively, if your installation is configured so that the server normally reads options from an option file, use the --defaults-file option to specify the file (enter each command on a single line):

shell> mysqld --defaults-file=/usr/local/mysql/etc/my.cnf
         --skip-grant-tables &
shell> mysql_upgrade

With the --skip-grant-tables option, the server does no password or privilege checking, so any client can connect and effectively have all privilges. For additional security, use the --skip-networking option as well to prevent remote clients from connecting.

For additional information, consult these references:

The unused and undocumented thread_pool_size system variable was removed. (Bug#57338)

The pstack library was nonfunctional and has been removed, along with the --with-pstack option for configure and the --enable-pstack option for mysqld. (Bug#57210)

Added a new SHOW PROCESSLIST state, Waiting for query cache lock. This indicates that a session is waiting to take the query cache lock while it performs some query cache operation. (Bug#56822)

A new status variable, Handler_read_last, displays the number of requests to read the last key in an index. With ORDER BY, the server will issue a first-key request followed by several next-key requests, whereas with With ORDER BY DESC, the server will issue a last-key request followed by several previous-key requests. (Bug#52312)

MySQL releases are now built using CMake rather than the GNU autotools. Accordingly, the instructions for installing MySQL from source have been updated to discuss how to build MySQL using CMake. See Section 2.11, “Installing MySQL from Source”. If you are familiar with autotools but not CMake, you might find this transition document helpful: http://forge.mysql.com/wiki/Autotools_to_CMake_Transition_Guide

The build process is now similar enough on all platforms, including Windows, that there are no longer sections dedicated to notes for specific platforms.

The default layout when compiling from source now matches that used for binary distributions. You will notice these differences for source installations:

The make_binary_distribution and make_win_bin_dist scripts are now obsolete. To create a binary distribution, use make package.

Performance: InnoDB Storage Engine: The master InnoDB background thread could sometimes cause transient performance drops due to excessive flushing of modified pages. (Bug#56933)

InnoDB Storage Engine: Incompatible Change: Security Fix: Issuing TRUNCATE TABLE and examining the same table's information in the INFORMATION_SCHEMA database at the same time could cause a crash in the debug version of the server.

As a result of this change, InnoDB always uses the fast truncation technique, equivalent to DROP TABLE and CREATE TABLE. It no longer performs a row-by-row delete for tables with parent-child foreign key relationships. TRUNCATE TABLE returns an error for such tables. Modify your SQL to issue DELETE FROM table_name for such tables instead. (Bug#54678)

Security Fix: The server crashed for assignment of values of types other than Geometry to items of type GeometryCollection (MultiPoint, MultiCurve, MultiSurface). Now the server checks the field type and fails with bad geometry value if it detects incorrect parameters. (Bug#55531)

Security Fix: The CONVERT_TZ() function crashed the server when the timezone argument was an empty SET column value. (Bug#55424)

Security Fix: EXPLAIN EXTENDED caused a server crash with some prepared statements. (Bug#54494)

Security Fix: In prepared-statement mode, EXPLAIN for a SELECT from a derived table caused a server crash. (Bug#54488)

Security Fix: The PolyFromWKB() function could crash the server when improper WKB data was passed to the function. (Bug#51875, CVE-2010-3840)

Incompatible Change: Replication: The behavior of INSERT DELAYED statements when using statement-based replication has changed as follows:

Previously, when using binlog_format=STATEMENT, a warning was issued in the client when executing INSERT DELAYED; now, no warning is issued in such cases.

Previously, when using binlog_format=STATEMENT, INSERT DELAYED was logged as INSERT DELAYED; now, it is logged as an INSERT, without the DELAYED option.

However, when binlog_format=STATEMENT, INSERT DELAYED continues to be executed as INSERT (without the DELAYED option). The behavior of INSERT DELAYED remains unchanged when using binlog_format=ROW: INSERT DELAYED generates no warnings, is executed as INSERT DELAYED, and is logged using the row-based format.

This change also affects binlog_format=MIXED, because INSERT DELAYED is no longer considered unsafe. Now, when the logging format is MIXED, no switch to row-based logging occurs. This means that the statement is logged as a simple INSERT (that is, without the DELAYED option), using the statement-based logging format. (Bug#54579)

See also Bug#56678, Bug#57666.

This regression was introduced by Bug#39934.

Incompatible Change: HANDLER ... READ statements that invoke stored functions can cause replication errors. Such statements are now disallowed and result in an ER_NOT_SUPPORTED_YET error. (Bug#54920)

Incompatible Change: Previously, if you flushed the logs using FLUSH LOGS or mysqladmin flush-logs and mysqld was writing the error log to a file (for example, if it was started with the --log-error option), it renamed the current log file with the suffix -old, then created a new empty log file. This had the problem that a second log-flushing operation thus caused the original error log file to be lost unless you saved it under a different name. For example, you could use the following commands to save the file:

shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory

To avoid the preceding file-loss problem, renaming no longer occurs. The server merely closes and reopens the log file. To rename the file, you can do so manually before flushing. Then flushing the logs reopens a new file with the original file name. For example, you can rename the file and create a new one using the following commands:

shell> mv host_name.err host_name.err-old
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory

(Bug#29751)

See also Bug#56821.

InnoDB Storage Engine: Replication: If the master had innodb_file_per_table=OFF, innodb_file_format=Antelope (and innodb_strict_mode=OFF), or both, certain CREATE TABLE options, such as KEY_BLOCK_SIZE, were ignored. This could allow master to avoid raising ER_TOO_BIG_ROWSIZE errors.

However, the ignored CREATE TABLE options were still written into the binary log, so that, if the slave had innodb_file_per_table=ON and innodb_file_format=Barracuda, it could encounter an ER_TOO_BIG_ROWSIZE error while executing the record from the log, causing the slave SQL thread to abort and replication to fail.

In the case where the master was running MySQL 5.1 and the slave was MySQL 5.5 (or later), the failure occurred when both master and slave were running with default values for innodb_file_per_table and innodb_file_format. This could cause problems during upgrades.

To address this issue, the default values for innodb_file_per_table and innodb_file_format are reverted to the MySQL 5.1 default values—that is, OFF and Antelope, respectively. (Bug#56318)

InnoDB Storage Engine: The server could crash with a high volume of concurrent LOCK TABLES and UNLOCK TABLES statements. (Bug#57345)

InnoDB Storage Engine: InnoDB incorrectly reported an error when a cascading foreign key constraint deleted more than 250 rows. (Bug#57255)

InnoDB Storage Engine: If the server crashed during an ALTER TABLE operation on an InnoDB table, examining the table through SHOW CREATE TABLE or querying the INFORMATION_SCHEMA tables could cause the server to stop with an assertion error. (Bug#56982)

InnoDB Storage Engine: The output from the SHOW ENGINE INNODB STATUS command can now be up to 1 MB. Formerly, it was truncated at 64 KB. Monitoring applications that parse can check if output exceeds this new, larger limit by testing the Innodb_truncated_status_writes status variable. (Bug#56922)

InnoDB Storage Engine: A SELECT ... FOR UPDATE statement affecting a range of rows in an InnoDB table could cause a crash in the debug version of the server. (Bug#56716)

InnoDB Storage Engine: Improved the performance of UPDATE operations on InnoDB tables, when only non-indexed columns are changed. (Bug#56340)

InnoDB Storage Engine: When MySQL was restarted after a crash with the option innodb_force_recovery=6, certain queries against InnoDB tables could fail, depending on WHERE or ORDER BY clauses.

Usually in such a disaster recovery situation, you dump the entire table using a query without these clauses. During advanced troubleshooting, you might use queries with these clauses to diagnose the position of the corrupted data, or to recover data following the corrupted part. (Bug#55832)

InnoDB Storage Engine: The CHECK TABLE command could cause a time-consuming verification of the InnoDB adaptive hash index memory structure. Now this extra checking is only performed in binaries built for debugging. (Bug#55716)

InnoDB Storage Engine: A heavy workload with a large number of threads could cause a crash in the debug version of the server. (Bug#55699)

InnoDB Storage Engine: The server could crash on shutdown, if started with --innodb-use-system-malloc=0. (Bug#55627)

InnoDB Storage Engine: If the server crashed during a RENAME TABLE operation on an InnoDB table, subsequent crash recovery could fail. This problem could also affect an ALTER TABLE statement that caused a rename operation internally. (Bug#55027)

InnoDB Storage Engine: Setting the PACK_KEYS=0 table option for an InnoDB table prevented new indexes from being added to the table. (Bug#54606)

InnoDB Storage Engine: The server could crash when opening an InnoDB table linked through foreign keys to a long chain of child tables. (Bug#54582)

InnoDB Storage Engine: Changed the locking mechanism for the InnoDB data dictionary during ROLLBACK operations, to improve concurrency for REPLACE statements. (Bug#54538)

InnoDB Storage Engine: With multiple buffer pools enabled, InnoDB could flush more data from the buffer pool than necessary, causing extra I/O overhead. (Bug#54346)

InnoDB Storage Engine: InnoDB transactions could be incorrectly committed during recovery, rather than rolled back, if the server crashed and was restarted after performing ALTER TABLE...ADD PRIMARY KEY on an InnoDB table, or some other operation that involves copying the entire table. (Bug#53756)

InnoDB Storage Engine: InnoDB startup messages now include the start and end times for buffer pool initialization, and the total buffer pool size. (Bug#48026)

Partitioning: An ALTER TABLE statement acting on table partitions that failed while the affected table was locked could cause the server to crash. (Bug#56172)

Partitioning: Multi-table UPDATE statements involving a partitioned MyISAM table could cause this table to become corrupted. Not all tables affected by the UPDATE needed to be partitioned for this issue to be observed. (Bug#55458)

Partitioning: EXPLAIN PARTITIONS returned bad estimates for range queries on partitioned MyISAM tables. In addition, values in the rows column of EXPLAIN PARTITIONS output did not take partition pruning into account. (Bug#53806, Bug#46754)

Replication: SET PASSWORD caused row-based replication to fail between a MySQL 5.1 master and a MySQL 5.5 slave.

This fix makes it possible to replicate SET PASSWORD correctly, using row-based replication between a master running MySQL 5.1.53 or a later MySQL 5.1 release to a slave running MySQL 5.5.7 or a later MySQL 5.5 release. (Bug#57098)

See also Bug#55452, Bug#57357.

Replication: Prepared multiple-row INSERT DELAYED statements were written to the binary log without DELAYED. (Bug#56678)

Replication: Backticks used to enclose idenitfiers for savepoints were not preserved in the binary log, which could lead to replication failure when the identifier, stripped of backticks, could be misinterpreted, causing a syntax or other error.

This could cause problems with MySQL application programs making use of generated savepoint IDs. If, for instance, java.sql.Connection.setSavepoint() is called without any parameters, Connector/J automatically generates a savepoint identifier consisting of a string of hexadecimal digits 0-F encased in backtick (`) characters. If such an ID took the form `NeN` (where N represents a string of the decimal digits 0-9, and e is a literal uppercase or lowercase “E” character). Removing the backticks when writing the identifier into the binary log left behind a substring which the slave MySQL server tried to interpret as a floating point number, rather than as an identifier. The resulting syntax error caused loss of replication. (Bug#55961)

See also Bug#55962.

Replication: When a slave tried to execute a transaction larger than the slave's value for max_binlog_cache_size, it crashed. This was caused by an assertion that the server should roll back only the statement but not the entire transaction when the error ER_TRANS_CACHE_FULL occurred. However, the slave SQL thread always rolled back the entire transaction whenever any error occurred, regardless of the type of error. (Bug#55375)

Replication: The error message for ER_SLAVE_HEARTBEAT_VALUE_OUT_OF_RANGE was hard coded in English in sql_yacc.yy, so that it could not be translated in errmsg.txt for other languages.

Additionally, this same error message was used for three separate error conditions:

These issues have been addressed as follows:

(Bug#54144)

A buffer overrun could occur when formatting DBL_MAX numbers. (Bug#57209)

COALESCE() in MySQL 5.5 could return a result different from MySQL 5.1 for some arguments. (Bug#57095)

Constant SUBTIME() expressions could return incorrect results. (Bug#57039)

When mysqld was started as a service on Windows and mysqld was writing the error log to a file (for example, if it was started with the --log-error option), the server reassign the file descriptors of the stdout and stderr streams to the file descriptor of the log file. On Windows, if stdout or stderr is not associated with an output stream, the file descriptor returns a negative value. Previously, this would cause the file descriptor reassignment to fail and the server to abort. To avoid this problem on Windows, stdout and stderr streams are now first assigned to the log file stream by opening this file. This causes stdout and stderr file descriptors to be nonzero and the server can successfully reassign them to the file descriptor of the log file. (Bug#56821)

The server could crash inside memcpy() when reading certain Performance Schema tables. (Bug#56761)

Deadlock could occur for a workload consisting of a mix of DML, DDL, and FLUSH TABLES statements affecting the same set of tables in a heavily concurrent environment. (Bug#56715, Bug#56404)

Memory leaks detected by Valgrind were corrected. (Bug#56709)

On Mac OS X, RENAME TABLE raised an assertion if the lower_case_table_names system variable was 2 and the old table name was specified in uppercase. (Bug#56595)

Performance for certain read-only queries, in particular point_select, had deteriorated compared to previous versions. (Bug#56585)

It was possible to compile mysqld with Performance Schema support but with a dummy atomic-operations implementation, which caused a server crash. This problem does not affect binary distributions. It is helpful as a safety measure for users who build MySQL from source. (Bug#56521)

Executing XA END after an XA transaction was already ended raised an assertion. (Bug#56448)

A SELECT statement could produce a different number of rows than a CREATE TABLE ... SELECT that was supposed to select the same rows. (Bug#56423)

The server crashed if a table maintenance statement such as ANALYZE TABLE or REPAIR TABLE was executed on a MERGE table and opening and locking a child table failed. For example, this could happen if a child table did not exist or if a lock timeout happened while waiting for a conflicting metadata lock to disappear.

As a consequence of this bug fix, it is now possible to use CHECK TABLE for log tables without producing an error. (Bug#56422, Bug#56494)

Deadlock could occur for heavily concurrent workloads consisting of a mix of DML, DDL, and FLUSH TABLES statements affecting the same set of tables. (Bug#56405)

ALTER TABLE on a MERGE table could result in deadlock with other connections. (Bug#56292, Bug#57002)

Comparison of one STR_TO_DATE() result with another could return incorrect results. (Bug#56271)

The tcmalloc library was missing from binary MySQL packages for Linux. (Bug#56267)

An INSERT DELAYED statement for a MERGE table could cause deadlock if it occurred as part of a transaction or under LOCK TABLES, and there was a concurrent DDL or LOCK TABLES ... WRITE statement that tried to lock one of its underlying tables. (Bug#56251)

In debug builds, the server raised an assertion for DROP DATABASE in installations that had an outdated or corrupted mysql.proc table. For example, this affected mysql_upgrade when run as part of a MySQL 5.1 to 5.5 upgrade. (Bug#56137)

A negative TIME argument to MIN() or MAX() could raise an assertion. (Bug#56120)

The ordering for supplementary characters with the utf8mb4_bin, utf16_bin, and utf32_bin collations was incorrect. (Bug#55980)

On Solaris with gcc 3.4.6, ha_example.so was built with DTrace support even if the server was not, causing plugin loading problems. (Bug#55966)

Short (single-letter) command-line options did not work. (Bug#55873)

If a query specified a DATE or DATETIME value in a format different from 'YYYY-MM-DD HH:MM:SS', a greater-than-or-equal (>=) condition matched only greater-than values in an indexed TIMESTAMP column. (Bug#55779)

If a view was named as the destination table for CREATE TABLE ... SELECT, the server produced a warning whether or not IF NOT EXISTS was used. Now it produces a warning only when IF NOT EXISTS is used, and an error otherwise. (Bug#55777)

CASE expressions with a mix of operands in different character sets sometimes returned incorrect results. (Bug#55744)

After the fix for Bug#39653, the shortest available secondary index was used for full table scans. The primary clustered key was used only if no secondary index could be used. However, when the chosen secondary index includes all columns of the table being scanned, it is better to use the primary index because the amount of data to scan is the same but the primary index is clustered. This is now taken into account. (Bug#55656)

The server entered an infinite loop with high CPU utilization after an error occurred during flushing of the IO cache. (Bug#55629)

For Performance Schema, the default number of rwlock classes was increased to 30, and the default number of rwlock and mutex instances was increased to 1 million. These changes were made to account for the volume of data instrumented when the InnoDB storage engine is used (because of the InnoDB buffer pool). (Bug#55576)

If there was an active SELECT statement, an error arising during trigger execution could cause a server crash. (Bug#55421)

Assignment of InnoDB scalar subquery results to a variable resulted in unexpected S locks in READ COMMITTED transation isolation level. (Bug#55382)

In debug builds, FLUSH TABLE table_list WITH READ LOCK for a MERGE table led to an assertion failure if one of the table's children was not present in the list of tables to be flushed. (Bug#55273)

The server could crash during shutdown due to a race condition relating to Performance Schema cleanup. (Bug#55105, Bug#56324)

Queries involving predicates of the form const NOT BETWEEN not_indexed_column AND indexed_column could return incorrect data due to incorrect handling by the range optimizer. (Bug#54802)

With an UPDATE IGNORE statement including a subquery that was evaluated using a temporary table, an error transferring the data from the temporary was ignored, causing an assertion to be raised. (Bug#54543)

A bad DBUG_PRINT statement in fill_schema_schemata() caused server crashes on Solaris. (Bug#54478)

MIN() or MAX() with a subquery argument could raise a debug assertion for debug builds or return incorrect data for nondebug builds. (Bug#54465)

If one session attempted to drop a database containing a table which another session had opened with HANDLER, any instance of ALTER DATABASE, CREATE DATABASE, or DROP DATABASE issued by the latter session produced a deadlock. (Bug#54360)

INFORMATION_SCHEMA plugins with no deinit() method resulted in a memory leak. (Bug#54253)

Row subqueries producing no rows were not handled as UNKNOWN values in row comparison expressions. (Bug#54190)

Setting SETUP_INSTRUMENTS.TIMER = 'NO' caused TIMER_WAIT values for aggregations to be NULL rather than 0. (Bug#53874)

The max_length metadata value of MEDIUMBLOB types was reported as 1 byte greater than the correct value. (Bug#53296)

If an application using the embedded server called mysql_library_init() a second time after calling mysql_library_init() and mysql_library_end() to start and stop the server, the application crashed when reading option files. (Bug#53251)

The fix for Bug#30234 caused the server to reject the DELETE tbl_name.* ... Access compatibility syntax for multiple-table DELETE statements. (Bug#53034)

The plugin_ftparser.h and plugin_audit.h include files are part of the public API/ABI, but were not tested by the ABI check. (Bug#52821)

An atomic “compare and swap” operation using x86 assembly code (32 bit) could access incorrect data, which would make it work incorrectly and lose the intended atomicity. This would in turn cause the MySQL server to work on inconsistent data structures and return incorrect data. That code part affected only 32-bit builds; the effect has been observed when icc was used to build binaries. With gcc, no incorrect results have been observed during tests, so this fix is a proactive one. Other compilers do not use this assembly code. (Bug#52419)

In LOAD DATA INFILE, using a SET clause to set a column equal to itself caused a server crash. (Bug#51850)

An assertion could be raised by DELETE on a view that referenced another view which in turn (directly or indirectly) referenced more than one table. (Bug#51099)

In some cases, when the left part of a NOT IN subquery predicate was a row and contained NULL values, the query result was incorrect. (Bug#51070)

CHECKSUM TABLE for Performance Schema tables could cause a server crash due to uninitialized memory reads. (Bug#50557)

For some queries, the optimizer produced incorrect results using the Index Merge access method with InnoDB tables. (Bug#50402)

EXPLAIN produced an incorrect rows value for queries evaluated using an index scan and that included LIMIT, GROUP BY, and ORDER BY on a computed column. (Bug#50394)

mysql_store_result() and mysql_use_result() are not for use with prepared statements and are not intended to be called following mysql_stmt_execute(), but failed to return an error when invoked that way. (Bug#47485)

Using REPAIR TABLE table USE_FRM on a MERGE table caused the server to crash. (Bug#46339)

If the global and session debug system variables had the same value, the debug trace file could be closed twice, leading to freeing already freed memory and a server crash. (Bug#46165)

If ALTER EVENT failed to load an event after altering it, an assertion could be raised. This could occur, for example, if ALTER EVENT was killed with KILL QUERY. (Bug#44171)

Trailing space removal for utf32 strings was done with non-multibyte-safe code, leading to incorrect result length and assertion failure. (Bug#42511)

A malformed packet sent by the server when the query cache was in use resulted in lost-connection errors. (Bug#42503)

Multiple-statement execution could fail. (Bug#40877)

CREATE TABLE failed if a column referred to in an index definition and foreign key definition was in different lettercases in the two definitions. (Bug#39932)

mysqlcheck behaved differently depending on the order in which options were given on the command line. (Bug#35269)

When invoked to display a help message, mysqld also displayed spurious warning or error messages. (Bug#30025)

Incompatible Change: The SHA2() function now returns a character string with the connection character set and collation. Previously, it returned a binary string. This is the same change made for several other encryption functions in MySQL 5.5.3. (Bug#54661)

Previously, MySQL-shared-compat RPMs for Linux contained both the current and previous client library versions for the target platform. Thus, the package contents overlapped with MySQL-shared RPMs, which contain only the current client library version. This can result in problems in two cases:

Now the MySQL-shared-compat RPMs include only older client library versions and no longer include the current version, so that the MySQL-shared and MySQL-shared-compat RPM contents no longer overlap. The MySQL-shared-compat RPM can be installed even if the MySQL-shared RPM is installed, without producing conflicts related to the current library version. The MySQL-shared-compat RPM can be uninstalled when old applications are removed or upgraded to the current library version, without breaking applications that already use the current library version.

If you previously installed the MySQL-shared-compat RPM because you needed both the current and previous libraries, you should install both the MySQL-shared and MySQL-shared-compat RPMs now. (Bug#56150)

Overhead for the Performance Schema interface was reduced. (Bug#55087)

Within stored programs, LIMIT clauses now accept integer-valued routine parameters or local variables as parameters. (Bug#11918)

Code was removed for the following no-longer-supported platforms: NetWare, MS-DOS, VMS, QNX, and 32-bit SPARC.

Performance: InnoDB Storage Engine: The setting innodb_change_buffering=all could produce slower performance for some operations than the previous default, innodb_change_buffering=inserts. (Bug#54914)

Performance: InnoDB Storage Engine: An EXPLAIN plan for an InnoDB table could vary greatly in the estimated cost for a BETWEEN clause. (Bug#53761)

InnoDB Storage Engine: Security Fix: After changing the values of the innodb_file_format or innodb_file_per_table configuration parameters, DDL statements could cause a server crash. (Bug#55039, CVE-2010-3676)

Security Fix: Replication: It was possible when using statement-based replication to subvert the MySQL privilege system on a slave with a higher server release version number than that of the master by using version-specific comments in statements run on the master. (Bug#49124)

Security Fix: During evaluation of arguments to extreme-value functions (such as LEAST() and GREATEST()), type errors did not propagate properly, causing the server to crash. (Bug#55826, CVE-2010-3833)

Security Fix: The server could crash after materializing a derived table that required a temporary table for grouping. (Bug#55568, CVE-2010-3834)

Security Fix: A user-variable assignment expression that is evaluated in a logical expression context can be precalculated in a temporary table for GROUP BY. However, when the expression value is used after creation of the temporary table, it was re-evaluated, not read from the table and a server crash resulted. (Bug#55564, CVE-2010-3835)

Security Fix: Joins involving a table with a unique SET column could cause a server crash. (Bug#54575, CVE-2010-3677)

Security Fix: Pre-evaluation of LIKE predicates during view preparation could cause a server crash. (Bug#54568, CVE-2010-3836)

Security Fix: Incorrect handling of NULL arguments could lead to a crash for IN() or CASE operations when NULL arguments were either passed explicitly as arguments (for IN()) or implicitly generated by the WITH ROLLUP modifier (for IN() and CASE). (Bug#54477, CVE-2010-3678)

Security Fix: GROUP_CONCAT() and WITH ROLLUP together could cause a server crash. (Bug#54476, CVE-2010-3837)

Security Fix: Queries could cause a server crash if the GREATEST() or LEAST() function had a mixed list of numeric and LONGBLOB arguments, and the result of such a function was processed using an intermediate temporary table. (Bug#54461, CVE-2010-3838)

Security Fix: A malformed argument to the BINLOG statement could result in Valgrind warnings or a server crash. (Bug#54393, CVE-2010-3679)

Security Fix: After ALTER TABLE was used on a temporary transactional table locked by LOCK TABLES, any later attempts to execute LOCK TABLES or UNLOCK TABLES caused a server crash. (Bug#54117)

Security Fix: Use of TEMPORARY InnoDB tables with nullable columns could cause a server crash. (Bug#54044, CVE-2010-3680)

Security Fix: Queries with nested joins could cause an infinite loop in the server when used from stored procedures and prepared statements. (Bug#53544, CVE-2010-3839)

Security Fix: Using EXPLAIN with queries of the form SELECT ... UNION ... ORDER BY (SELECT ... WHERE ...) could cause a server crash. (Bug#52711, CVE-2010-3682)

Incompatible Change: Replication: As of MySQL 5.5.6, handling of CREATE TABLE IF NOT EXISTS ... SELECT statements has been changed for the case that the destination table already exists:

This change in handling of IF NOT EXISTS results in an incompatibility for statement-based replication from a MySQL 5.1 master with the original behavior and a MySQL 5.5 slave with the new behavior. Suppose that CREATE TABLE IF NOT EXISTS ... SELECT is executed on the master and the destination table exists. The result is that rows are inserted on the master but not on the slave. (Row-based replication does not have this problem.)

To address this issue, statement-based binary logging for CREATE TABLE IF NOT EXISTS ... SELECT is changed in MySQL 5.1 as of 5.1.51:

This change provides forward compatibility for statement-based replication from MySQL 5.1 to 5.5 because when the destination table exists, the rows will be inserted on both the master and slave. To take advantage of this compatibility measure, the 5.1 server must be at least 5.1.51 and the 5.5 server must be at least 5.5.6.

To upgrade an existing 5.1-to-5.5 replication scenario, upgrade the master first to 5.1.51 or higher. Note that this differs from the usual replication upgrade advice of upgrading the slave first.

A workaround for applications that wish to achieve the original effect (rows inserted regardless of whether the destination table exists) is to use CREATE TABLE IF NOT EXISTS and INSERT ... SELECT statements rather than CREATE TABLE IF NOT EXISTS ... SELECT statements.

Along with the change just described, the following related change was made: Previously, if an existing view was named as the destination table for CREATE TABLE IF NOT EXISTS ... SELECT, rows were inserted into the underlying base table and the statement was written to the binary log. As of MySQL 5.1.51 and 5.5.6, nothing is inserted or logged. (Bug#47442, Bug#47132, Bug#48814, Bug#49494)

Incompatible Change: Several changes were made to Performance Schema tables:

(Bug#55416)

Incompatible Change: Handling of warnings and errors during stored program execution was problematic:

(Bug#36185, Bug#5889, Bug#9857, Bug#23032)

Incompatible Change: If the server was started with character_set_server set to utf16, it crashed during full-text stopword initialization. Now the stopword file is loaded and searched using latin1 if character_set_server is ucs2, utf16, or utf32. If any table was created with FULLTEXT indexes while the server character set was ucs2, utf16, or utf32, it should be repaired using this statement:

REPAIR TABLE tbl_name QUICK;

(Bug#32391)

Important Change: Replication: The LOAD DATA INFILE statement is now considered unsafe for statement-based replication. When using statement-based logging mode, the statement now produces a warning; when using mixed-format logging, the statement is made using the row-based format. (Bug#34283)

InnoDB Storage Engine: An assertion was raised if (1) an InnoDB table was created using CREATE TABLE ... SELECT where the query used an INFORMATION_SCHEMA table and a view existed in the database; or (2) any statement that modified an InnoDB table had a subquery referencing an INFORMATION_SCHEMA table. (Bug#55973)

InnoDB Storage Engine: The InnoDB storage engine was not included in the default installation when using the configure script. (Bug#55547)

InnoDB Storage Engine: For an InnoDB table with an auto-increment column, the server could crash if the first statement that references the table after a server restart is a SHOW CREATE TABLE statement. (Bug#55277)

InnoDB Storage Engine: The mysql_config tool would not output the requirement for the aio library for mysqld-libs. (Bug#55215)

InnoDB Storage Engine: Some memory used for InnoDB asynchronous I/O was not freed at shutdown. (Bug#54764)

InnoDB Storage Engine: Implementation of the 64-bit dulint structure in InnoDB was not optimized for 64-bit processors, resulting in excessive storage and reduced performance. (Bug#54728)

InnoDB Storage Engine: The output from the SHOW ENGINE INNODB STATUS command now includes information about “spin rounds” for RW-locks (both shared and exclusive locks). (Bug#54726)

InnoDB Storage Engine: An ALTER TABLE statement could convert an InnoDB compressed table (with row_format=compressed) back to an uncompressed table (with row_format=compact). (Bug#54679)

InnoDB Storage Engine: InnoDB could issue an incorrect message on startup, if tables were created under the setting innodb_file_per_table=ON. The message was of the form InnoDB: Warning: allocated tablespace n, old maximum was 0 and is no longer displayed during restarts after you have upgraded the MySQL server and created at least one InnoDB table with innodb_file_per_table=ON. If you continue to encounter this message, you might have corruption in your shared tablespace; if so, back up and reload your data. (Bug#54658)

InnoDB Storage Engine: The database server could crash when renaming a table that had active transactions. (This issue only affected the database server when built for debugging.) (Bug#54453)

InnoDB Storage Engine: The server could crash during the recovery phase of startup, if it previously crashed while inserting BLOB or other large columns that use off-page storage into an InnoDB table created with ROW_FORMAT=REDUNDANT or ROW_FORMAT=COMPACT. (Bug#54408)

InnoDB Storage Engine: For an InnoDB table created with ROW_FORMAT=COMPRESSED or ROW_FORMAT=DYNAMIC, a query using the READ UNCOMMITTED isolation level could cause the server to stop with an assertion error, if BLOB or other large columns that use off-page storage were being inserted at the same time. (Bug#54358)

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

InnoDB Storage Engine: If a session executing TRUNCATE TABLE on an InnoDB table was killed during open_tables(), an assertion could be raised. (Bug#53757)

InnoDB Storage Engine: Misimplementation of the os_fast_mutex_trylock() function in InnoDB resulted in unnecessary blocking and reduced performance. (Bug#53204)

InnoDB Storage Engine: InnoDB could not create tables that used the utf32 character set. (Bug#52199)

InnoDB Storage Engine: Performing large numbers of RENAME TABLE statements caused excessive memory use. (Bug#47991)

InnoDB Storage Engine: The mechanism that checks if there is enough space for redo logs was improved, reducing the chance of encountering this message: ERROR: the age of the last checkpoint is x, which exceeds the log group capacity y. (Bug#39168)

InnoDB Storage Engine: Improved performance and scalability on Windows systems, especially for Windows Vista and higher. Re-enabled the use of atomic instructions on Windows systems. For Windows Vista and higher, reduced the number of event handles used. To compile on Windows systems now requires Windows SDK v6.0 or later; either upgrade to Visual Studio 2008 or 2010, or for Visual Studio 2005, install Windows SDK Update for Windows Vista. (Bug#22268)

Partitioning: With innodb_thread_concurrency = 1, ALTER TABLE ... REORGANIZE PARTITION and SELECT could deadlock. There were unreleased latches in the ALTER TABLE ... REORGANIZE PARTITION thread which were needed by the SELECT thread to be able to continue. (Bug#54747)

Partitioning: An ALTER TABLE ... ADD PARTITION statement run concurrently with a read lock caused spurious ER_TABLE_EXISTS and ER_NO_SUCH_TABLE errors on subsequent attempts. (Bug#53676)

See also Bug#53770.

Partitioning: UPDATE and INSERT statements affecting partitioned tables performed poorly when using row-based replication. (Bug#52517)

Partitioning: INSERT ON DUPLICATE KEY UPDATE statements performed poorly on tables having many partitions. This was because the handler function for reading a row from a specific index was not optimized in the partitioning handler. (Bug#52455)

Partitioning: ALTER TABLE ... TRUNCATE PARTITION, when called concurrently with transactional DML on the table, was executed immediately and did not wait for the concurrent transaction to release locks. As a result, the ALTER TABLE statement was written into the binary log before the DML statement, which led to replication failures when using row-based logging. (Bug#49907)

See also Bug#42643.

Partitioning: When the storage engine used to create a partitioned table was disabled, attempting to drop the table caused the server to crash. (Bug#46086)

Replication: When using the row-based logging format, a failed CREATE TABLE ... SELECT statement was written to the binary log, causing replication to break if the failed statement was later re-run on the master. In such cases, a DROP TABLE ... IF EXIST statement is now logged in the event that a CREATE TABLE ... SELECT fails. (Bug#55625)

Replication: When using the row-based logging format, a SET PASSWORD statement was written to the binary log twice. (Bug#55452)

Replication: When closing temporary tables, after the session connection was already closed, if the writing of the implicit DROP TABLE statement into the binary log failed, it was possible for the resulting error to be mishandled, triggering an assertion. (Bug#55387)

Replication: Executing SHOW BINLOG EVENTS increased the value of max_allowed_packet applying to the session that executed the statement. (Bug#55322)

Replication: Setting binlog_format = ROW then creating and then dropping a temporary table led an assertion. (Bug#54925)

Replication: When using mixed-format replication, changes made to a non-transactional temporary table within a transaction were not written into the binary log when the transaction was rolled back. This could lead to a failure in replication if the temporary table was used again afterwards. (Bug#54872)

See also Bug#53259.

Replication: If binlog_format was explicitly switched from STATEMENT to ROW following the creation of a temporary table, then on disconnection the master failed to write the expected DROP TEMPORARY TABLE statement into the binary log. As a consequence, temporary tables (and their corresponding files) accumulated as this scenario was repeated. (Bug#54842)

See also Bug#52616.

Replication: If the SQL thread was started while the I/O thread was performing rotation of the relay log, the 2 threads could begin to race for the same I/O cache, leading to a crash of the server. (Bug#54509)

See also Bug#50364.

Replication: Two related issues involving temporary tables and transactions were introduced by a fix made in MySQL 5.1.37:

The current fix restores the correct behavior in both of these cases. (Bug#53560)

This regression was introduced by Bug#43929.

Replication: The value of binlog_direct_non_transactional_updates had no effect on statements mixing transactional tables and nontransactional tables, or mixing temporary tables and nontransactional tables.

As part of the fix for this issue, updates to temporary tables are now handled as transactional or nontransactional according to their storage engine types. (In effect, the current fix reverts a change made previously as part of the fix for Bug#53259.)

In addition, unsafe mixed statements (that is, statements which access transactional table as well nontransactional or temporary tables, and write to any of them) are now handled as transactional when the statement-based logging format is in use. (Bug#53452)

See also Bug#51894.

Replication: When binlog_format=STATEMENT, any statement that is flagged as being unsafe, possibly causing the slave to go out of sync, generates a warning. This warning is written to the server log, the warning count is returned to the client in the server's response, and the warnings are accessible through SHOW WARNINGS.

The current bug affects only the counts for warnings to the client and that are visible through SHOW WARNINGS; it does not affect which warnings are written to the log. The current issue came about because the fix for an earlier issue caused warnings for substatements to be cleared whenever a new substatement was started. However, this suppressed warnings for unsafe statements in some cases. Now, such warnings are no longer cleared. (Bug#50312)

This regression was introduced by Bug#36649.

Replication: Replication could break if a transaction involving both transactional and nontransactional tables was rolled back to a savepoint. It broke if a concurrent connection tried to drop a transactional table which was locked after the savepoint was set. This DROP TABLE completed when ROLLBACK TO SAVEPOINT was executed because the lock on the table was dropped by the transaction. When the slave later tried to apply the binary log events, it would fail because the table had already been dropped. (Bug#50124)

Replication: When CURRENT_USER() or CURRENT_USER was used to supply the name and host of the affected user or of the definer in any of the statements DROP USER, RENAME USER, GRANT, REVOKE, and ALTER EVENT, the reference to CURRENT_USER() or CURRENT_USER was not expanded when written to the binary log. This resulted in CURRENT_USER() or CURRENT_USER being expanded to the user and host of the slave SQL thread on the slave, thus breaking replication. Now CURRENT_USER() and CURRENT_USER are expanded prior to being written to the binary log in such cases, so that the correct user and host are referenced on both the master and the slave. (Bug#48321)

After an RPM installation mysqld would be started with the root, rather than the mysql user. (Bug#56574)

The embedded server raised an assertion when it attempted to load plugins. (Bug#56085)

FORMAT() did not respect the decimal point character if the locale was changed and always returned an ASCII value. (Bug#55912)

CMake produced bad dependencies for the sql/lex_hash.h file during configuration. (Bug#55842)

mysql_upgrade did not handle the --ssl option properly. (Bug#55672)

Using MIN() or MAX() on a column containing the maximum TIME value caused a server crash. (Bug#55648)

Incorrect handling of user variable assignments as subexpressions could lead to incorrect results or server crashes. (Bug#55615)

The default compiler options used for Mac OS X 10.5 were set incorrectly. (Bug#55601)

The server was not checking for errors generated during the execution of Item::val_xxx() methods when copying data to a group, order, or distinct temp table's row. (Bug#55580)

ORDER BY clauses that included user variable expressions could cause a debug assertion to be raised. (Bug#55565)

SHOW CREATE TRIGGER took a stronger metadata lock than required. This caused the statement to be blocked unnecessarily. For example, LOCK TABLES ... WRITE in one session blocked SHOW CREATE TRIGGER in another session.

Also, a SHOW CREATE TRIGGER statement issued inside a transaction did not release its metadata locks at the end of statement execution. Consequently, SHOW CREATE TRIGGER was able to block other sessions from accessing the table (for example, using ALTER TABLE). (Bug#55498)

A single-table DELETE ordered by a column that had a hash-type index could raise an assertion or cause a server crash. (Bug#55472)

A call to mysql_library_init() following a call to mysql_library_end() caused a client crash. (Bug#55345)

A statement that was aborted by KILL QUERY while it waited on a metadata lock could raise an assertion in debug builds, or send OK to the client instead of ER_QUERY_INTERRUPTED in regular builds. (Bug#55223)

GROUP BY operations used max_sort_length inconsistently. (Bug#55188)

The Windows MSI installer would fail to preserve custom settings, such as the configured data directory, during installation. (Bug#55169)

InnoDB produced no warning at startup about illegal innodb_file_format_check values. (Bug#55095)

IF() with a subquery argument could raise a debug assertion for debug builds under some circumstances. (Bug#55077)

Building MySQL on Solaris 8 x86 failed when using Sun Studio due to gcc inline assembly code. (Bug#55061)

When upgrading an existing install with an RPM on Linux, the MySQL server might not have been restarted properly. This was due to a naming conflict when upgrading from a community named RPM. Previous installations are now correctly removed, and the MySQL init script are recreated and then start the MySQL server as normal. (Bug#55015)

The thread_concurrency system variable was unavailable on non-Solaris systems. (Bug#55001)

mysqld_safe contained a syntax error that prevented it from restarting the server. (Bug#54991)

If audit plugins were installed that were interested in MYSQL_AUDIT_GENERAL_CLASS events and the general query log was disabled, failed INSTALL PLUGIN or UNINSTALL PLUGIN statements caused a server crash. (Bug#54989)

Some functions did not calculate their max_length metadata value correctly. (Bug#54916)

A SHOW CREATE TABLE statement issued inside a transaction did not release its metadata locks at the end of statement execution. Consequently, SHOW CREATE TABLE was able to block other sessions from accessing the table (for example, using ALTER TABLE). (Bug#54905)

INFORMATION_SCHEMA.ENGINES and SHOW ENGINES described MyISAM as the default storage engine, but this is not true as of MySQL 5.5.5. (Bug#54832)

The MERGE storage engine tried to use memory mapping on the underlying MyISAM tables even on platforms that do not support it and even when myisam_use_mmap was disabled. This led to a hang for INSERT INTO ... SELECT FROM statements that selected from a MyISAM table into a MERGE table that contained the same MyISAM table. (Bug#54811, Bug#50788)

Incorrect error handling could result in an OPTIMIZE TABLE crash. (Bug#54783)

Performance Schema event collection for a thread could “leak” from one connection to another if the thread was used for one connection, then cached, then reused for another connection. (Bug#54782)

In debug builds, an assertion could be raised when the server tried to send an OK packet to the client after having failed to detect errors during processing of the WHERE condition of an UPDATE statement. (Bug#54734)

In a slave SQL thread or Event Scheduler thread, the SLEEP() function could not sleep more than five seconds. (Bug#54729)

SET sql_select_limit = 0 did not work. (Bug#54682)

Assignments of the PASSWORD() or OLD_PASSWORD() function to a user variable did not preserve the character set of the function return value. (Bug#54668)

A signal-handler redefinition for SIGUSR1 was removed. The redefinition could cause the server to encounter a kernel deadlock on Solaris when there are many active threads. Other POSIX platforms might also be affected. (Bug#54667)

Queries that named view columns in a GROUP BY clause could cause a server crash. (Bug#54515)

Performance Schema displayed spurious startup error messages when the server was run in bootstrap mode. (Bug#54467)

For distributions built with cmake rather than the GNU autotools, mysql lacked pager support. (Bug#54466)

The server failed to disregard sort order for some zero-length tuples, leading to an assertion failure. (Bug#54459)

A join with an aggregated function and impossible WHERE condition returned an extra row. (Bug#54416)

Errors during processing of WHERE conditions in HANDLER ... READ statements were not detected, so the handler code still tried to send EOF to the client, raising an assertion. (Bug#54401)

If a session tried to drop a database containing a table opened with HANDLER in another session, any DATABASE statement (CREATE, DROP, ALTER) executed by that session produced a deadlock. (Bug#54360)

Deadlocks involving INSERT DELAYED statements were not detected. The server could crash if the delayed handler thread was killed due to a conflicting shared metadata lock. (Bug#54332)

For distributions built with cmake rather than the GNU autotools, some scripts were built without the execute bit set. (Bug#54129)

After ALTER TABLE was used on a temporary transactional table locked by LOCK TABLES, any later attempts to execute LOCK TABLES or UNLOCK TABLES caused a server crash. (Bug#54117)

INSERT IGNORE INTO ... SELECT statements could cause a debug assertion to be raised. (Bug#54106)

SHOW CREATE EVENT released all metadata locks held by the current transaction. This invalidated any existing savepoints and raised an assertion if ROLLBACK TO SAVEPOINT was executed. (Bug#54105)

A client could supply data in chunks to a prepared statement parameter other than of type TEXT or BLOB using the mysql_stmt_send_long_data() C API function (or COM_STMT_SEND_LONG_DATA command). This led to a crash because other data types are not valid for long data. (Bug#54041)

mysql_secure_installation did not properly identify local accounts and could incorrectly remove nonlocal root accounts. (Bug#54004)

A client with automatic reconnection enabled saw the error message Lost connection to MySQL server during query if the connection was lost between the mysql_stmt_prepare() and mysql_stmt_execute() C API functions. However, mysql_stmt_errno() returned 0, not the corresponding error number 2013. (Bug#53899)

INFORMATION_SCHEMA.COLUMNS reported incorrect precision for BIGINT UNSIGNED columns. (Bug#53814)

The patch for Bug#36569 caused performance regressions and incorrect execution of some UPDATE statments. (Bug#53737, Bug#53742)

Missing Performance Schema tables were not reported in the error log at server startup. (Bug#53617)

mysql_upgrade could incorrectly remove TRIGGER privileges. (Bug#53613)

SHOW ENGINE PERFORMANCE_SCHEMA STATUS underreported the amount of memory allocated by Performance Schema. (Bug#53566)

Portability problems in SHOW STATUS could lead to incorrect results on some platforms. (Bug#53493)

Builds of MySQL generated a large number of warnings. (Bug#53445)

Performance Schema header files were not installed in the correct directory. (Bug#53255)

The server could crash when processing subqueries with empty results. (Bug#53236)

With lower_case_table_names set to a nonzero value, searches for table or database names in INFORMATION_SCHEMA tables could produce incorrect results. (Bug#53095)

Use of uint in typelib.h caused compilation problems in Windows. This was changed to unsigned int. (Bug#52959)

The mysql-debug.pdb supplied with releases did not match the corresponding mysqld.exe. (Bug#52850)

The PERFORMANCE_SCHEMA database was not correctly created and populated on Windows. (Bug#52809)

The large_pages system variable was tied to the --large-files command-line option, not the --large-pages option. (Bug#52716)

Attempts to access a nonexistent table in the performance_schema database resulted in a misleading error message. (Bug#52586)

The ABI check for MySQL failed to compile with gcc 4.5. (Bug#52514)

Performance Schema could enter an infinite loop if required to create a large number of mutex instances. (Bug#52502)

mysql_secure_installation sometimes failed to locate the mysql client. (Bug#52274)

Some queries involving GROUP BY and a function that returned DATE raised a debug assertion. (Bug#52159)

If a symbolic link was used in a file path name, the Performance Schema did not resolve all file io events to the same name. (Bug#52134)

PARTITION BY KEY on a utf32 ENUM column raised a debugging assertion. (Bug#52121)

A pending FLUSH TABLES tbl_list WITH READ LOCK statement unnecessarily aborted transactions. (Bug#52117)

FLUSH TABLES WITH READ LOCK in one session and FLUSH TABLES tbl_list WITH READ LOCK in another session were mutually exclusive.

This bug fix involved several changes to the states displayed by SHOW PROCESSLIST:

(Bug#52044)

Reading a ucs2 data file with LOAD DATA INFILE was subject to three problems. 1) Incorrect parsing of the file as ucs2 data, resulting in incorrect length of the parsed string. This is fixed by truncating the invalid trailing bytes (incomplete multibyte characters) when reading from the file. 2) Reads from a proper ucs2 file did not recognize newline characters. This is fixed by first checking whether a byte is a newline (or any other special character) before reading it as a part of a multibyte character. 3) When using user variables to hold column data, the character set of the user variable was set incorrectly to the database charset. This is fixed by setting it to the character set specified in the LOAD DATA INFILE statement, if any. (Bug#51876)

XA START had a race condition that could cause a server crash. (Bug#51855)

The results of some ORDER BY ... DESC queries were sorted incorrectly. (Bug#51431)

Index Merge between three indexes could return incorrect results. (Bug#50389)

MIN() and MAX() returned incorrect results for DATE columns if the set of values included '0000-00-00'. (Bug#49771)

Searches in INFORMATION_SCHEMA tables for rows matching a nonexistent database produced an error instead of an empty query result. (Bug#49542)

DROP DATABASE failed if there was a TEMPORARY table with the same name as a non-TEMPORARY table in the database. (Bug#48067)

An assertion occurred in ha_myisammrg.cc line 1137:

  DBUG_ASSERT(this->file->children_attached);

The problem was found while running RQG tests and the assertion occurred during REPAIR, OPTIMIZE, and ANALYZE operations. (Bug#47633)

The optimize method of the ARCHIVE storage engine did not preserve the FRM embedded in the ARZ file when rewriting the ARZ file for optimization. This meant an ARCHIVE table that had been optimized could not be discovered.

The ARCHIVE engine stores the FRM in the ARZ file so it can be transferred from machine to machine without also needing to copy the FRM file. The engine subsequently restores the embedded FRM during discovery. (Bug#45377)

With character_set_connection set to utf16 or utf32, CREATE TABLE t1 AS SELECT HEX() ... caused a server crash. (Bug#45263)

The my_like_range_xxx() functions returned badly formed maximum strings for Asian character sets, which caused problems for storage engines. (Bug#45012)

A debugging assertion could be raised after a write failure to a closed socket. (Bug#42496)

Enumeration plugin variables were subject to a type casting error, causing inconsistent results between different platforms. (Bug#42144)

Sort-index_merge for join tables other than the first table used excessive memory. (Bug#41660)

DROP TABLE held a lock during unlink() file system operations, causing performance problems if unlink() took a long time. (Bug#41158)

Rows inserted in a table by one session were not immediately visible to another session that queried the table, even if the insert had committed. (Bug#37521)

Statements of the form UPDATE ... WHERE ... ORDER BY used a filesort even when not required. (Bug#36569)

See also Bug#53737, Bug#53742.

Reading from a temporary MERGE table, with two non-temporary child MyISAM tables, resulted in the error:

ERROR 1168 (HY000): Unable to open underlying table which is differently 
defined or of non-MyISAM type or doesn't exist

(Bug#36171)

safemalloc was excessively slow under certain conditions and has been removed. The --skip-safemalloc server option has also been removed, and the --with-debug=full configuration option is no different from --with-debug. (Bug#34043)

Threads that were calculating the estimated number of records for a range scan did not respond to the KILL statement. That is, if a range join type is possible (even if not selected by the optimizer as a join type of choice and thus not shown by EXPLAIN), the query in the statistics state (shown by the SHOW PROCESSLIST) did not respond to the KILL statement. (Bug#25421)

Problems in the atomic operations implementation could lead to server crashes. (Bug#22320, Bug#52261)

This is the final release of MySQL 5.5 for which Generic Linux MySQL binary packages built with the icc compiler on x86 and x86_64 will be offered. These were previously produced as an alternative to our main packages built using gcc, as they provided noticeable performance benefits. In recent times the performance differences have diminished and build and runtime problems have surfaced, thus it is no longer viable to continue producing them.

We continue to use the icc compiler to produce our distribution-specific RPM packages on ia64.

InnoDB has been upgraded to version 1.1.1. This version is considered of “early adopter” quality.

InnoDB is now the default storage engine, rather than MyISAM, in the regular and enterprise versions of MySQL. This change has the following consequences:

Follow these steps to ensure a smooth transition:

Incompatible Change: All numeric operators and functions on integer, floating-point and DECIMAL values now throw an “out of range” error (ER_DATA_OUT_OF_RANGE) rather than returning an incorrect value or NULL, when the result is out of the supported range for the corresponding data type. See Section 10.6, “Out-of-Range and Overflow Handling”. (Bug#8433)

InnoDB Storage Engine: The INFORMATION_SCHEMA.INNODB_TRX table now includes a number of new fields that duplicate information from the SHOW ENGINE INNODB STATUS output. You no longer need to parse that output to get complete transaction information. (Bug#53336)

InnoDB Storage Engine: InnoDB stores redo log records in a hash table during recovery. On 64-bit systems, this hash table was 1/8 of the buffer pool size. To reduce memory usage, the dimension of the hash table was reduced to 1/64 of the buffer pool size (or 1/128 on 32-bit systems). (Bug#53122)

Previously, the innodb_file_format_check system variable served a dual purpose. Setting it at server startup would keep InnoDB from starting if any tables used a more recent file format than supported by the current level of InnoDB. If InnoDB could start, the same system variable was set to the “highest” file format value used by any InnoDB table in the database. Thus, its value could change from the value you specified.

Now, checking and recording the file format tag are handled using separate variables. innodb_file_format_check can be set to 1 or 0 at server startup to enable or disable whether InnoDB checks the file format tag in the system tablespace. If the tag is checked and is higher than that supported by the current version of InnoDB, an error occurs and InnoDB does not start. If the tag is not higher, InnoDB sets the value of innodb_file_format_max to the file format tag.

For background information about InnoDB file-format management, see Section 13.7.4, “InnoDB File Format Management”. (Bug#49792, Bug#53654)

The Rows_examined value in slow query log rows now is nonzero for UPDATE and DELETE statements that modify rows. (Bug#49756)

The deprecated mysql_fix_privilege_tables script has been removed. (Bug#42589)

There is a new system variable, skip_name_resolve, that is set from the value of the --skip-name-resolve server option. This provides a way to determine at runtime whether the server uses name resolution for client connections. (Bug#37168)

Added the SHA2() function, which calculates the SHA-2 family of hash functions (SHA-224, SHA-256, SHA-384, and SHA-512). (Contributed by Bill Karwin) (Bug#13174)

It is now possible to build MySQL on all platforms using CMake instead of the GNU autotools. (Prior to MySQL 5.5.5, CMake support was limited to Windows.) For instructions on using CMake to build MySQL, see http://forge.mysql.com/wiki/CMake.

Performance: InnoDB Storage Engine: Deadlock detection could be a bottleneck in InnoDB processing, if many transactions attempted to update the same row simultaneously. The algorithm has been improved to enhance performance and scalability, in the InnoDB Plugin for MySQL 5.1, and in InnoDB 1.1 for MySQL 5.5. (Bug#49047)

Performance: While looking for the shortest index for a covering index scan, the optimizer did not consider the full row length for a clustered primary key, as in InnoDB. Secondary covering indexes will now be preferred, making full table scans less likely. (Bug#39653)

See also Bug#55656.

Security Fix: The server could crash if there were alternate reads from two indexes on a table using the HANDLER interface. (Bug#54007, CVE-2010-3681)

Security Fix: The server failed to check the table name argument of a COM_FIELD_LIST command packet for validity and compliance to acceptable table name standards. This could be exploited to bypass almost all forms of checks for privileges and table-level grants by providing a specially crafted table name argument to COM_FIELD_LIST.

In MySQL 5.0 and above, this permitted an authenticated user with SELECT privileges on one table to obtain the field definitions of any table in all other databases and potentially of other MySQL instances accessible from the server's file system.

Additionally, for MySQL version 5.1 and above, an authenticated user with DELETE or SELECT privileges on one table could delete or read content from any other table in all databases on this server, and potentially of other MySQL instances accessible from the server's file system. (Bug#53371, CVE-2010-1848)

Security Fix: The server was susceptible to a buffer-overflow attack due to a failure to perform bounds checking on the table name argument of a COM_FIELD_LIST command packet. By sending long data for the table name, a buffer is overflown, which could be exploited by an authenticated user to inject malicious code. (Bug#53237, CVE-2010-1850)

Security Fix: LOAD DATA INFILE did not check for SQL errors and sent an OK packet even when errors were already reported. Also, an assert related to client/server protocol checking in debug servers sometimes was raised when it should not have been. (Bug#52512, CVE-2010-3683)

Security Fix: Privilege checking for UNINSTALL PLUGIN was incorrect. (Bug#51770, CVE-2010-1621)

Security Fix: The server could be tricked into reading packets indefinitely if it received a packet larger than the maximum size of one packet. (Bug#50974, CVE-2010-1849)

Incompatible Change: TRUNCATE TABLE did not take an exclusive lock on a table if truncation was done by deleting all rows in the table. For InnoDB tables, this could break proper isolation because InnoDB ended up aborting some granted locks when truncating a table. Now an exclusive metadata lock is taken before TRUNCATE TABLE can proceed. This guarantees that no other transaction is using the table.

Incompatible change: Truncation using delete no longer fails if sql_safe_updates is enabled (this was an undocumented side effect). (Bug#42643)

Incompatible Change: After SET TRANSACTION ISOLATION LEVEL to set the isolation level for the next transaction, the session value of the tx_isolation system variable could appear to change after completion of statements within the transaction to the transaction isolation level. Now the current transaction isolation level is now established at transaction start. If there was a SET TRANSACTION ISOLATION LEVEL statement, the value is taken from it. Otherwise, the session tx_isolation value is used. A change in the session value while a transaction is active is still allowed, but no longer affects the current transaction isolation level. This is an incompatible change. A change in the session isolation level made while there is no active transaction overrides a SET TRANSACTION ISOLATION LEVEL statement, if there was any. (Bug#20837)

Important Change: Replication: It was possible to set sql_log_bin with session scope inside a transaction or subquery. (Bug#53437)

Important Change: Replication: When changing binlog_format or binlog_direct_non_transactional_updates, permissions were not checked prior to checking the scope and context of the variable being changed.

As a result of this fix, an error is no longer reported when—in the context of a transaction or a stored function—you try to set a value for a session variable that is the same as its previous value, or for a variable whose scope is global only. (Bug#51277)

Important Change: Replication: When invoked, CHANGE MASTER TO and SET GLOBAL sql_slave_skip_counter now cause information to be written to the error log about the slave's state prior to execution of the statement. For CHANGE MASTER TO, this information includes the previous values for MASTER_HOST, MASTER_PORT, MASTER_LOG_FILE, and MASTER_LOG_POS. For SET GLOBAL sql_slave_skip_counter, this information includes the previous values of sql_slave_skip_counter, the group relay log name, and the group relay log position. (Bug#43406, Bug#43407)

Important Change: When using fast ALTER TABLE, different internal ordering of indexes in the MySQL optimizer and the InnoDB storage engine could cause error messages about possibly mixed up .frm files and incorrect index use. (Bug#47622)

InnoDB Storage Engine: Replication: TRUNCATE TABLE performed on a temporary table using the InnoDB storage engine was logged even when using row-based mode. (Bug#51251)

InnoDB Storage Engine: Replication: Reading from a table that used a self-logging storage engine and updating a table that used a transactional engine (such as InnoDB) generated changes that were written to the binary log using statement format which could make slaves diverge. However, when using mixed logging format, such changes should be written to the binary log using row format. (This issue did not occur when reading from tables using a self-logging engine and updating MyISAM tables, as this was already handled by checking for combinations of non-transactional and transactional engines.) Now such statements are classified as unsafe, and in mixed mode, cause a switch to row-based logging. (Bug#49019)

InnoDB Storage Engine: The server could crash during shutdown, if started with the option --innodb_use_sys_malloc=0. (Bug#54453)

InnoDB Storage Engine: The server could crash with a message InnoDB: Assertion failure in thread nnnn, typically during shutdown on a Windows system. (Bug#53947)

InnoDB Storage Engine: Some combinations of SELECT and SELECT FOR UPDATE statements could fail with errors about locks, or incorrectly release a row lock during a semi-consistent read operation. (Bug#53674)

InnoDB Storage Engine: Adding a unique key on multiple columns, where one of the columns is null, could mistakenly report duplicate key errors. (Bug#53290)

InnoDB Storage Engine: Fixed a checksum error reported for compressed tables when the --innodb_checksums option is enabled. Although the message stated that the table was corrupted, the table is actually fine after the fix. (Bug#53248)

InnoDB Storage Engine: When reporting a foreign key constraint violation during INSERT, InnoDB could display uninitialized data for the DB_TRX_ID and DB_ROLL_PTR system columns. (Bug#53202)

InnoDB Storage Engine: The values of innodb_buffer_pool_pages_total and innodb_buffer_pool_pages_misc in the information_schema.global_status table could be computed incorrectly. (Bug#52983)

InnoDB Storage Engine: InnoDB page splitting could enter an infinite loop for compressed tables. (Bug#52964)

InnoDB Storage Engine: An overly strict assertion could fail during the purge of delete-marked records in DYNAMIC or COMPRESSED InnoDB tables that contain column prefix indexes. (Bug#52746)

InnoDB Storage Engine: InnoDB attempted to choose off-page storage without ensuring that there was an “off-page storage” flag in the record header. To correct this, in DYNAMIC and COMPRESSED formats, InnoDB stores locally any non-BLOB columns having a maximum length not exceeding 256 bytes. This is because there is no room for the “external storage” flag when the maximum length is 255 bytes or less. This restriction trivially holds in REDUNDANT and COMPACT formats, because there InnoDB always stores locally columns having a length up to local_len = 788 bytes. (Bug#52745)

InnoDB Storage Engine: Connections waiting for an InnoDB row lock ignored KILL until the row lock wait ended. Now, KILL during lock wait results in “query interrupted” instead of “lock wait timeout exceeded”. The corresponding transaction is rolled back. (Bug#51920)

InnoDB Storage Engine: InnoDB checks to see whether a row could possibly exceed the maximum size if all columns are fully used. This produced Row size too large errors for some tables that could be created with the built-in InnoDB from older MySQL versions. Now the check is only done when innodb_strict_mode is enabled or if the table is dynamic or compressed. (Bug#50495)

InnoDB Storage Engine: Multi-statement execution could fail with an error about foreign key constraints. This problem could affect calls to mysql_query() and mysql_real_query(), and CALL statements that invoke stored procedures. (Bug#48024)

InnoDB Storage Engine: A mismatch between index information maintained within the .frm files and the corresponding information in the InnoDB system tablespace could produce this error: [ERROR] Index index of table has n columns unique inside InnoDB, but MySQL is asking statistics for m columns. Have you mixed up .frm files from different installations? (Bug#44571)

Partitioning: Replication: Attempting to execute LOAD DATA on a partitioned MyISAM table while using statement-based logging mode caused the master to hang or crash. (Bug#51851)

Partitioning: Replication: The NO_DIR_IN_CREATE server SQL mode was not enforced when defining subpartitions. In certain cases, this could lead to failures on replication slaves. (Bug#42954)

Partitioning: Rows inserted into a table created using a PARTITION BY LIST COLUMNS option referencing multiple columns could be inserted into the wrong partition. (Bug#52815)

Partitioning: Partition pruning on RANGE partitioned tables did not always work correctly; the last partition was not excluded if the range was beyond it (when not using MAXVALUE). Now the last partition is not included if the partitioning function value is not within the range. (Bug#51830)

Partitioning: Attempting to partition a table using a DECIMAL column caused the server to crash; this not supported and is now specifically not permitted. (Bug#51347)

Partitioning: ALTER TABLE statements that cause table partitions to be renamed or dropped (such as ALTER TABLE ... ADD PARTITION, ALTER TABLE ... DROP PARTITION, and ALTER TABLE ... REORGANIZE PARTITION) — when run concurrently with queries against the INFORMATION_SCHEMA.PARTITIONS table — could fail, cause the affected partitioned tables to become unusable, or both. This was due to the fact that the INFORMATION_SCHEMA database ignored the name lock imposed by the ALTER TABLE statement on the partitions affected. In particular, this led to problems with InnoDB tables, because InnoDB would accept the rename operation, but put it in a background queue, so that subsequent rename operations failed when InnoDB was unable to find the correct partition. Now, INFORMATION_SCHEMA honors name locks imposed by ongoing ALTER TABLE statements that cause partitions to be renamed or dropped. (Bug#50561)

See also Bug#47343, Bug#45808.

Partitioning: The insert_id server system variable was not reset following an insert that failed on a partitioned MyISAM table having an AUTO_INCREMENT column. (Bug#50392)

Partitioning: Foreign keys are not supported on partitioned tables. However, it was possible using an ALTER TABLE statement to set a foreign key on a partitioned table; it was also possible to partition a table with a single foreign key. (Bug#50104)

Partitioning: It was possible to execute a CREATE TEMPORARY TABLE tmp LIKE pt statement, where pt is a partitioned table, even though partitioned temporary tables are not permitted, which caused the server to crash. Now a check is performed to prevent such statements from being executed. (Bug#49477)

Partitioning: When attempting to perform DDL on a partitioned table and the table's .par file could not be found, the server returned the inaccurate error message Out of memory; restart server and try again (needed 2 bytes). Now in such cases, the server returns the error Failed to initialize partitions from .par file. (Bug#49161)

Partitioning: GROUP BY queries performed poorly for some partitioned tables. This was due to the block size not being set for partitioned tables, thus the keys per block was not correct, which could cause such queries to be optimized incorrectly. (Bug#48229)

See also Bug#37252.

Partitioning: REPAIR TABLE failed for partitioned ARCHIVE tables. (Bug#46565)

Replication: When using unique keys on NULL columns in row-based replication, the slave sometimes chose the wrong row when performing an update. This happened because a table having a unique key on such a column could have multiple rows containing NULL for the column used by the unique key, and the slave merely picked the first row containing NULL in that column. (Bug#53893)

Replication: When a CREATE TEMPORARY TABLE ... SELECT statement was executed within a transaction that updated only transactional engines and was later rolled back (for example, due to a deadlock) the changes—including the creation of the temporary table—were not written to the binary log, which caused subsequent updates to this table to fail on the slave. (Bug#53421)

Replication: When using the statement-based logging format, statements that used CONNECTION_ID() were always kept in the transaction cache; consequently, nontransactional changes that should have been flushed before the transaction were kept in the transaction cache. (Bug#53075)

This regression was introduced by Bug#51894.

Replication: In some cases, attempting to update a column with a value of an incompatible type resulted in a mismatch between master and slave because the column value was set to its implicit default value on the master (as expected), but the same column on the slave was set to NULL. (Bug#52868)

Replication: ACK packets in semisynchronous replication were not checked for length and malformed packets could cause a server crash. (Bug#52748)

Replication: When temporary tables were in use, switching the binary logging format from STATEMENT to ROW did not take effect until all temporary tables were dropped. (The existence of temporary tables should prevent switching the format only from ROW to STATEMENT from taking effect, not the reverse.) (Bug#52616)

Replication: A buffer overrun in the handling of DATE column values could cause mysqlbinlog to fail when reading back logs containing certain combinations of DML on a table having a DATE column followed by dropping the table. (Bug#52202)

Replication: The failure of a REVOKE statement was logged with the wrong error code, causing replication slaves to stop even when the failure was expected on the master. (Bug#51987)

Replication: Issuing any DML on a temporary table temp followed by DROP TEMPORARY TABLE temp, both within the same transaction, caused replication to fail.

The fix introduces a change to statement-based binary logging with respect to temporary tables. Within a transaction, changes to temporary tables are saved to the transaction cache and written to the binary log when the transaction commits. Otherwise, out-of-order logging of events could occur. This means that temporary tables are treated similar to transactional tables for purposes of caching and logging. This affects assessment of statements as safe or unsafe and the associated error message was changed from:

Unsafe statement written to the binary log using statement format
since BINLOG_FORMAT = STATEMENT. Statements that read from both
transactional and non-transactional tables and write to any of them
are unsafe.

To:

Unsafe statement written to the binary log using statement format
since BINLOG_FORMAT = STATEMENT. Statements that read from both
transactional (or a temporary table of any engine type) and
non-transactional tables and write to any of them are unsafe.

(Bug#51894)

See also Bug#51291, Bug#53075, Bug#53259, Bug#53452, Bug#54872.

This regression was introduced by Bug#46364.

Replication: The flag stating whether a user value was signed or unsigned (unsigned_flag) could sometimes change between the time that the user value was recorded for logging purposes and the time that the value was actually written to the binary log, which could lead to inconsistency. Now unsigned_flag is copied when the user variable value is copied, and the copy of unsigned_flag is then used for logging. (Bug#51426)

See also Bug#49562.

Replication: Enabling binlog_direct_non_transactional_updates causes nontransactional changes to be written to the binary log upon committing the statement. However, even when not enabled, the addition of this variable introduced a number of undesired changes in behavior:

These problems have been handled as follows:

(Bug#51291)

This regression was introduced by Bug#46364.

Replication: When using temporary tables the binary log needs to insert a pseudo-thread ID for threads that are using temporary tables, each time a switch happens between two threads, both of which are using temporary tables. However, if a thread issued a failing statement before exit, its ID was not recorded in the binary log, and this in turn caused the ID for the next thread that tried to do something with a temporary table not to be logged as well. Subsequent replays of the binary log failed with the error Table ... doesn't exist. (Bug#51226)

Replication: If the master was using sql_mode='TRADITIONAL', duplicate key errors were not sent to the slave, which received 0 rather than the expected error code. This caused replication to fail even when such an error was expected. (Bug#51055)

Replication: DDL statements that lock tables (such as ALTER TABLE, CREATE INDEX, and CREATE TRIGGER) caused spurious ER_BINLOG_ROW_MODE_AND_STMT_ENGINE or ER_BINLOG_STMT_MODE_AND_ROW_ENGINE errors, even though they did not insert rows into any tables.

(Bug#50479)

This regression was introduced by Bug#39934.

Replication: When run with the --database option, mysqlbinlog printed ROLLBACK statements but did not print any corresponding SAVEPOINT statements. (Bug#50407)

Replication: When a CREATE EVENT statement was followed by an additional statement and the statements were executed together as a single statement, the CREATE EVENT statement was padded with “garbage” characters when written to the binary log, which led to a syntax error when trying to read back from the log. (Bug#50095)

Replication: When using a non-transactional table on the master with autocommit disabled, no COMMIT was recorded in the binary log following a statement affecting this table. If the slave's copy of the table used a transactional storage engine, the result on the slave was as though a transaction had been started, but never completed. (Bug#49522)

See also Bug#29288.

The make_binary_distribution target to make could fail on some platforms because the lines generated were too long for the shell. (Bug#54590)

Inconsistent checking of the relationship between SHOW statements and INFORMATION_SCHEMA queries caused such queries to fail sometimes. (Bug#54422)

A crash occurred if a table that was locked with LOCK TABLES was listed twice in a DROP TABLE statement. (Bug#54282)

ALTER TABLE for views is not legal but did not produce an error. (If you need to rename a view, use RENAME TABLE.) (Bug#53976)

Valgrind warnings resulting from passing incomplete DATETIME values to the TIMESTAMP() function were corrected. (Bug#53942)

Builds of the embedded mysqld would fail due to a missing element of the struct NET. (Bug#53908, Bug#53912)

The definition of the MY_INIT macro in my_sys.h included an extraneous semicolon, which could cause compilation failure. (Bug#53906)

Queries that used MIN() or MAX() on indexed columns could be optimized incorrectly. (Bug#53859)

UPDATE on an InnoDB table modifying the same index that was used to satisfy the WHERE condition could trigger a debug assertion under some circumstances. (Bug#53830)

MySQL incorrectly processed ALTER DATABASE `#mysql50#<special>` UPGRADE DATA DIRECTORY NAME where <special> was ., .., or a sequence starting with ./ or ../. It used the server data directory (that contains other regular databases) as the database directory. (Bug#53804, CVE-2010-2008)

OPTIMIZE TABLE could be run on a table in use by a transaction in a different session, causing repeatable read to break. (Bug#53798)

InnoDB crashed when replacing duplicates in a table after a fast ALTER TABLE added a unique index. (Bug#53592)

For InnoDB tables, the error handler for a fast CREATE INDEX did not reset the error state of the transaction before attempting to undo a failed operation, resulting in a crash. (Bug#53591)

For single-table DELETE statements that used quick select and index scan simultaneously caused a server crash or assertion failure. (Bug#53450)

Certain path names passed to LOAD_FILE() could cause a server crash. (Bug#53417)

If the completion_type session variable was changed after a stored procedure or prepared statement had been cached, the change had no effect on subsequent executions of the procedure or statement. (Bug#53346)

The AND CHAIN option for COMMIT and ROLLBACK failed to preserve the current transaction isolation level. Setting completion_type to 1 also failed to do so. (Bug#53343)

Incorrect results could be returned for LEFT JOIN of InnoDB tables with an impossible WHERE condition. (Bug#53334)

The Lock_time value in the slow query log was negative for stored routines. (Bug#53191)

Setting the innodb_change_buffering system variable to DEFAULT produced an incorrect result. (Bug#53165)

mysqldump and SELECT ... INTO OUTFILE truncated long BLOB and TEXT values to 766 bytes. (Bug#53088)

On some systems, such as Mac OS X, the sockaddr_in and sockaddr_in6 structures contain a non-standard field (sin_len / sin6_len) that must be set but was not. This resulted in hostname lookup failure. (Bug#52923)

In the debug version of the server, the FreeState() function could in some circumstances be called twice, leading to an assertion failure. (Bug#52884)

Concurrent SHOW COLUMNS statements could cause a server crash. (Bug#52856)

With a non-latin1 ASCII-based current character set, the server inappropriately converted DATETIME values to strings. This resulted in the optimizer not using indexes on such columns. (Bug#52849)

mysqld_safe set plugin_dir using a default path name rather than a path depending on basedir. (Bug#52737)

Semi-consistent read was implemented for InnoDB to address Bug#3300. Semi-consistent reads do not block when a nonmatching record is already locked by some other transaction. If the record is not locked, a lock is acquired, but is released if the record does not match the WHERE condition. However, semi-consistent read was attempted even for UPDATE statements having a WHERE condition of the form pk_col1=constant1, ..., pk_colN=constantN. Some code that was designed with the assumption that semi-consistent read would be only attempted on table scans, failed. (Bug#52663)

Setting @@GLOBAL.debug to an empty string failed to clear the current debug settings. (Bug#52629)

SHOW CREATE TABLE was blocked if the table was write locked by another session. (Bug#52593)

The length and max_length metadata values were incorrect for columns with the TEXT family of data types that used multibyte character sets This bug was introduced in MySQL 5.5.3. (Bug#52520)

mysql_upgrade attempted to work with stored routines before they were available. (Bug#52444)

The check_table_is_closed() debugging function did not protect access to the MyISAM open tables list, with the result that server crashes could occur during table drop or rename operations. (Bug#52432)

Spurious duplicate-key errors occurred for multiple-column indexes on columns with the BINARY data type. (Bug#52430)

EXPLAIN EXTENDED crashed trying to resolve references to freed temporary table columns for GROUP_CONCAT() ORDER BY arguments. (Bug#52397)

During installing of MySQL server using the MSI package on Windows, the default-character-set option would be included in the default configuration template file. This would cause the MySQL server to fail to start properly. (Bug#52380)

Two sessions trying to set the global event_scheduler system variable to OFF resulted in one of them hanging waiting for the event scheduler to stop. (Bug#52367)

There was a race condition between flags used for signaling that a query was killed, which led to error-reporting and lock-acquisition problems. (Bug#52356)

For a concurrent load of 16 or more connections containing many LOCK TABLES WRITE statements for the same table, server throughput was significantly lower for MySQL 5.5.3 and 5.5.4 than for earlier versions (10%–40% lower depending on concurrency). (Bug#52289)

Operations on geometry data types failed on some systems for builds compiled with Sun Studio. (Bug#52208)

The optimizer could attempt to evaluate the WHERE clause before any rows had been read, resulting in a server crash. (Bug#52177)

Cast operations on NULL DECIMAL values could cause server crashes or Valgrind warnings. (Bug#52168)

An assertion was raised as a result of a NULL string being passed to the dtoa code. (Bug#52165)

A memory leak occurred due to missing deallocation of the comparators array (a member of the Arg_comparator class). (Bug#52124)

For debug builds, creating a view containing a subquery that might require collation adjustment caused an assertion to be raised. For example, this could occur if some items had different collations but the result collation could be adjusted to the one of them. (Bug#52120)

Aggregate functions could incorrectly return NULL in outer join queries. (Bug#52051)

For outer joins, the optimizer could fail to properly calculate table dependencies. (Bug#52005)

A COUNT(DISTINCT) query on a view could cause a server crash. (Bug#51980)

For LDML-defined collations, some data structures were not initialized properly to enable UPPER() and LOWER() to work correctly. (Bug#51976)

On Windows, LOAD_FILE() could cause a crash for some pathnames. (Bug#51893)

Invalid memory reads occurred for HANDLER ... READ NEXT after a failed HANDLER ... READ FIRST. (Bug#51877)

After TRUNCATE TABLE of a MyISAM table, subsequent queries could crash the server if myisam_use_mmap was enabled. (Bug#51868)

If myisam_sort_buffer_size was set to a small value, table repair for MyISAM tables with FULLTEXT indexes could crash the server. (Bug#51866)

Stored routine DDL statements were written to the binary log using statement-based format regardless of the current logging format. (Bug#51839)

A problem with equality propagation optimization for prepared statements and stored procedures caused a server crash upon re-execution of the prepared statement or stored procedure. (Bug#51650)

See also Bug#8115, Bug#8849.

The optimizer performed an incorrect join type when COALESCE() appeared within an IN() operation. (Bug#51598)

Locking involving the LOCK_plugin, LOCK_global_system_variables, and LOCK_status mutexes could deadlock. (Bug#51591)

Executing a LOAD XML INFILE statement could sometimes lead to a crash of the MySQL Server. (Bug#51571)

The server crashed when the optimizer attempted to determine constant tables but a table storage engine did not support exact record count. (Bug#51494)

The server could crash populating the INFORMATION_SCHEMA.PROCESSLIST table due to lack of mutex protection. (Bug#51377)

Use of HANDLER statements with tables that had spatial indexes caused a server crash. (Bug#51357)

With an XA transaction active, SET autocommit = 1 could cause side effects such as memory corruption or a server crash. (Bug#51342)

Corrupt MyISAM tables were automatically repaired even when myisam_recover_options was set to OFF. (Bug#51327)

Following a bulk insert into a MyISAM table, if MyISAM failed to build indexes using repair by sort, data file corruption could occur. (Bug#51307)

CHECKSUM TABLE could compute the checksum for BIT columns incorrectly. (Bug#51304)

ALTER TABLE on InnoDB tables (including partitioned tables) acquired exclusive locks on rows of the table being altered. If there was a concurrent transaction that did locking reads from this table, this sometimes led to a deadlock that was not detected by the metadata lock subsystem or by InnoDB (and was reported only after exceeding innodb_lock_wait_timeout). (Bug#51263)

A HAVING clause on a joined table in some cases failed to eliminate rows which should have been excluded from the result set. (Bug#51242)

Two sessions trying to set the global event_scheduler system variable to different values could deadlock. (Bug#51160)

InnoDB fast index creation could incorrectly use a table copy in some cases. (Bug#50946)

The Loose Index Scan optimization method assumed that it could depend on the partitioning engine to maintain interval endpoint information, as if it were a storage engine. (Bug#50939)

The type inference used for view columns caused some columns in views to be handled as the wrong type, as compared to the same columns in base tables. DATE columns in base tables were treated as TIME columns in views, and base table TIME columns as view DATETIME columns. (Bug#50918)

A syntactically invalid trigger could cause the server to crash when trying to list triggers. (Bug#50755)

Previously, the server held a global mutex while performing file operations such as deleting an .frm or data file, or reading table metadata from an .frm file or index statistics from a data file. Now the mutex is not held for these operations. Instead, the server uses metadata locks. (Bug#50589, Bug#51557, Bug#49463)

User-defined variables of type REAL that contained NULL were handled improperly when assigned to a column of another type. (Bug#50511)

Setting --secure-file-priv to the empty string left the value unaffected. (Bug#50373)

Calculation of intervals for Event Scheduler events was not portable. (Bug#50087)

The YEAR values 2000 and 0000 could be treated as equal. (Bug#49910)

Performing a single in-place ALTER TABLE containing ADD INDEX and DROP INDEX options that used the same index name could result in a corrupt table definition file. Now such ALTER TABLE statements are no longer performed in place. (Bug#49838)

mysql_upgrade did not detect when CSV log tables incorrectly contained columns that could be NULL. Now these columns are altered to be NOT NULL. (Bug#49823)

support-files/mysql.spec.sh had unnecessary Perl dependencies. (Bug#49723)

Selecting from INFORMATION_SCHEMA.ROUTINES or INFORMATION_SCHEMA.PARAMETERS resulted in a memory leak. (Bug#48729)

In MySQL 5.1, READ COMMITTED was changed to use less locking due to the availability of row based binary logging (see the Note under READ COMMITTED at Section 12.3.6, “SET TRANSACTION Syntax”). However, READ UNCOMMITTED did not have the same change, so it was using more locks than the higher isolation level, which is unexpected. This was changed so that READ UNCOMMITTED now also uses the lesser amount of locking and has the same restrictions for binary logging. (Bug#48607)

On Intel x86 machines, the optimizer could choose different execution plans for a query depending on the compiler version and optimization flags used to build the server binary. (Bug#48537)

A trigger could change the behavior of assigning NULL to a NOT NULL column. (Bug#48525)

The server crashed when it could not determine the best execution plan for queries involving outer joins with nondeterministic ON clauses such as the ones containing the RAND() function, a user-defined function, or a NOT DETERMINISTIC stored function. (Bug#48483)

EXPLAIN could cause a server crash for some queries with subqueries. (Bug#48419)

The MERGE engine failed to open a child table from a different database if the child table or database name contained characters that were the subject of table name to filename encoding.

Further, the MERGE engine did not properly open a child table from the same database if the child table name contained characters such as '/', '#'. (Bug#48265)

On Windows, the server failed to find a description for Event ID 100. (Bug#48042)

A query that read from a derived table (of the form SELECT ... FROM (SELECT ...)) produced incorrect results when the following conditions were present:

(Bug#47904)

The optimization to read MIN() or MAX() values from an index did not properly handle comparisons with NULL values. This could produce incorrect results for MIN() or MAX()when the WHERE clause tested a NOT NULL column for NULL. (Bug#47762)

Killing a query during the optimization phase of a subquery could cause a server crash. (Bug#47761)

Using REPLACE to update a previously inserted negative value in an AUTO_INCREMENT coumn in an InnoDB table caused the table auto-increment value to be updated to 2147483647. (Bug#47720)

The query shown by EXPLAIN EXTENDED plus SHOW WARNINGS could produce results different from the original query. (Bug#47669)

MyISAM could write uninitialized data to new index pages. Now zeros are written to unused bytes in the pages. (Bug#47598)

OPTIMIZE TABLE for an InnoDB table could raise an assertion if another session issued a concurrent DROP TABLE. (Bug#47459)

For updates to InnoDB tables, TIMESTAMP columns could be updated even when no values actually changed. (Bug#47453)

Setting myisam_repair_threads larger than 1 could result in the cardinality for all indexes of a MyISAM table being set to 1 after parallel index repair. (Bug#47444)

mysqld_safe did not always pass --open-files-limit through to mysqld. mysqld_safe did not treat dashes and underscores as equivalent in option names. (Bug#47095)

For events of MYSQL_AUDIT_GENERAL_CLASS, the event subclass was not passed to audit plugins even though the server passed the subclass to the plugin handler. The subclass is now available through the following changes:

The example plugin in the plugin/audit_null directory has been modified to count events of each subclass, based on the event_subclass value. See Section 23.2.5.2, “Writing Audit Plugins”. (Bug#47059)

When the transaction isolation level was REPEATABLE READ and binary logging used statement or mixed format, SELECT statements with subqueries referencing InnoDB tables unnecessarily acquired shared locks on rows in these tables. (Bug#46947)

In debug builds, if the listed columns in the view definition of the table used in an INSERT ... SELECT statement mismatched, an assertion was raised in the query cache invalidation code following the failing statement. (Bug#46615)

For the COMMIT and ROLLBACK statements, the AND CHAIN and RELEASE modifiers should be mutually exclusive, but the parser allowed both to be specified. (Bug#46527)

If the server is started with --skip-grant-tables, plugin loading and unloading should be prohibited, but the server failed to reject INSTALL PLUGIN and UNINSTALL PLUGIN statements. (Bug#46261)

gcc 4.4.0 could fail to compile dtoa.c. (Bug#45882)

ALTER TABLE ... ADD COLUMN for a table with multiple foreign keys caused a server crash. (Bug#45052)

Manual pages for a few little-used programs were missing from RPM packages. (Bug#44370)

Using an initial command with mysql_options(..., MYSQL_INIT_COMMAND, ...) that generated multiple result sets (such as a stored procedure or a multi-statement command) left the connection unusable. (Bug#42373)

The server could crash with an out of memory error when trying to parse a query that was too long to fit in memory. Now the parser rejects such queries with an ER_OUT_OF_RESOURCES error. (Bug#42064)

InnoDB could fail to create a unique index on NULL columns. (Bug#41904)

For a query that selected from a view and used an alias for the view, the metadata used the alias name rather than the view name in the MYSQL_FIELD.table member. (Bug#41788)

mysql_upgrade did not create temporary files properly. (Bug#41057)

It was possible for DROP TABLE of one MyISAM table to remove the data and index files of a different MyISAM table. (Bug#40980)

If the arguments to a CONCAT() call included a local routine variable, selecting the return value into a user variable could produce an incorrect result. (Bug#40625)

Column names displayed from the PARTITION_EXPRESSION column of the INFORMATION_SCHEMA.PARTITIONS table did not include escape characters as necessary. (Bug#39338)

When SET TRANSACTION ISOLATION LEVEL was used to set the isolation level for the next transaction, the level could persist for subsequent transactions. (Bug#39170)

When using UNINSTALL PLUGIN to remove a loaded plugin, open tables and connections caused mysqld to hang until the open connections had been closed. (Bug#39053)

Valgrind warnings in the InnoDB compare_record() function were corrected. (Bug#38999)

The optimizer sometimes used filesort for ORDER BY when it should have used an index. (Bug#38745)

Setting the session value of the debug system variable also set the global value. (Bug#38054)

Accessing a MERGE table with an empty underlying table list incorrectly resulted in a “wrong index” error message rather than “end of file.” (Bug#35274)

The test for readline during configuration failed when trying to build MySQL in a directory other than the source tree root. (Bug#35250)

mysqld could fail during execution when using SSL. (Bug#34236)

A query on a FEDERATED table in which the data was ordered by a TEXT column returned incorrect results. For example, a query such as the following would result in incorrect results if column column1 was a TEXT column:

SELECT * FROM table1 ORDER BY column1;

(Bug#32426)

MySQL Makefiles relied on GNU extensions. (Bug#30708)

The parser allocated too much memory for a query containing multiple statements. (Bug#27863)

The behavior of the RPM installation for both new installations and upgrade installations has changed.

During a new installation, the server boot scripts are installed, but the MySQL server is not started at the end of the installation, since the status of the system during an unattended installation is not known.

During an upgrade installation using the RPM packages, if the server is running when the upgrade occurs, the server is stopped, the upgrade occurs, and server is restarted. If the server is not already running when the RPM upgrade occurs, the server is not started at the end of the installation.

The boot scripts for MySQL are installed in the appropriate directories in /etc, so the MySQL server will be restarted automatically at the next machine reboot. (Bug#27072)

ROW_COUNT() returned a meaningful value only for some DML statements. Now it returns a value as follows:

(Bug#21818)

InnoDB has been upgraded to version 1.1. This version is considered of Beta quality.

For information about InnoDB features, see Section 13.7, “New Features of InnoDB 1.1”. For general information about using InnoDB in MySQL, see Section 13.6, “The InnoDB Storage Engine”.

InnoDB Storage Engine: InnoDB now has a innodb_use_native_aio system variable that can be disabled at startup if there is a problem with the asynchronous I/O subsystem in the OS. This variable applies to Linux systems only, where the MySQL server now has a dependency on the libaio library.

Performance: InnoDB Storage Engine: The redo scan during InnoDB recovery used excessive CPU. The efficiency of this scan was improved, significantly speeding up crash recovery. (Bug#49535, Bug#29847)

Performance: InnoDB Storage Engine: InnoDB page-freeing operations were made faster for compressed blocks, speeding up ALTER TABLE, DROP TABLE, and other operations on compressed tables that free compressed blocks. One symptom of the older behavior could be 100% CPU use during these operations. (Bug#35077)

InnoDB Storage Engine: The AIX implementation of readdir_r() caused InnoDB errors. (Bug#50691)

InnoDB Storage Engine: The limit of 1023 concurrent data-modifying transactions has been raised. The limit is now 128 * 1023 concurrent transactions that generate undo records. You can remove any workarounds that require changing the proper structure of your transactions, such as committing more frequently or delaying DML operations to the end of a transaction. See Section 13.7.7.19, “Better Scalability with Multiple Rollback Segments”. (Bug#26590)

A unique index on a column prefix could not be upgraded to a primary index even if there was no primary index already defined. (Bug#51378)

InnoDB did not reset table AUTO_INCREMENT values to the last used values after a server restart. (Bug#49032)

When using the EXAMPLE storage engine, when the engine had been built as a plugin (instead of built-in), and DTrace probes had been enabled during the build, loading the storage engine library would fail due to a missing object table entry.

MySQL Server now includes Performance Schema, a feature for monitoring server execution at a low level. It is implemented using the PERFORMANCE_SCHEMA storage engine and the performance_schema database. Performance Schema focuses primarily on performance data. This differs from INFORMATION_SCHEMA, which serves for inspection of metadata. For more information, see Chapter 21, MySQL Performance Schema.

Performance Schema support is included in binary MySQL distributions. It is disabled by default. To enable it, start the server with the --performance_schema option.

To create the performance_schema database if you are upgrading from an earlier release, run mysql_upgrade and restart the server. See Section 4.4.7, “mysql_upgrade — Check Tables for MySQL Upgrade”.

This release includes InnoDB 1.0.6. This version is considered of Release Candidate (RC) quality.

Performance: The performance of internal functions that trim multiple spaces from strings when comparing them has been improved. (Bug#14637)

Incompatible Change: The following obsolete constructs have been removed. Where alternatives are shown, applications should be updated to use them.

(Bug#48048)

See also Bug#47974, Bug#56408.

Incompatible Change: Aliases for wildcards (as in SELECT t.* AS 'alias' FROM t) are no longer accepted and result in an error. Previously, such aliases were ignored silently. (Bug#27249)

Incompatible Change: Implicit conversion of a number or temporal value to string now produces a value that has a character set and collation determined by the character_set_connection and collation_connection system variables. (These variables commonly are set with SET NAMES. For information about connection character sets, see Section 9.1.4, “Connection Character Sets and Collations”.)

This means that such a conversion results in a character (nonbinary) string (a CHAR, VARCHAR, or LONGTEXT value), except in the case that the connection character set is set to binary. In that case, the conversion result is a binary string (a BINARY, VARBINARY, or LONGBLOB value).

Previously, an implicit conversion always produced a binary string, regardless of the connection character set. Such implicit conversions to string typically occur for functions that are passed numeric or temporal values when string values are more usual, and thus could have effects beyond the type of the converted value. Consider the expression CONCAT(1, 'abc'). The numeric argument 1 was converted to the binary string '1' and the concatenation of that value with the nonbinary string 'abc' produced the binary string '1abc'.

This change in conversion behavior affects several functions that expect string arguments because a numeric or temporal argument converted to a string now results in a character rather than binary string argument:

These functions remain unaffected:

Encryption and compression functions that expect string arguments and previously returned binary strings are affected depending on the content of the return value:

The INET_NTOA() return value contains only ASCII characters, and this function now returns a character string with the connection character set and collation rather than a binary string.

Incompatible Change: Several changes were made to processing of server system variables and command-line options to make their treatment more consistent.

General changes:

Variable-specific changes:

See also Bug#34437, Bug#34635.

Incompatible Change: FLUSH TABLES has a new variant, FLUSH TABLES tbl_list WITH READ LOCK. This variant enables tables to be flushed and locked in a single operation. It provides a workaround for the restriction (due to work done for Bug#989) that FLUSH TABLES is not permitted when there is an active LOCK TABLES ... READ.

See also Bug#42465.

Incompatible Change: The server now includes dtoa, a library for conversion between strings and numbers by David M. Gay. In MySQL, this library provides the basis for improved conversion between string or DECIMAL values and approximate-value (FLOAT/DOUBLE) numbers:

Because the conversions produced by this library differ in some cases from previous results, the potential exists for incompatibilities in applications that rely on previous results. For example, applications that depend on a specific exact result from previous conversions might need adjustment to accommodate additional precision.

For additional information about the properties of dtoa conversions, see Section 11.2, “Type Conversion in Expression Evaluation”.

See also Bug#12860, Bug#21497, Bug#26788, Bug#24541, Bug#34015.

Incompatible Change: The Unicode implementation has been extended to provide support for supplementary characters that lie outside the Basic Multilingual Plane (BMP). Noteworthy features:

In most respects, upgrading to MySQL 5.5 should present few problems with regard to Unicode usage, although there are some potential areas of incompatibility. These are the primary areas of concern:

Consequently, if you want to upgrade tables from utf8 to utf8mb4 to take advantage of supplementary-character support, it may be necessary to change some column or index definitions.

For additional details about the new Unicode character sets and potential incompatibilities, see Section 9.1.10, “Unicode Support”, and Section 9.1.11, “Upgrading from Previous to Current Unicode Support”.

Incompatible Change: Several columns were added to the INFORMATION_SCHEMA.ROUTINES table to provide information about the RETURNS clause data type for stored functions: DATA_TYPE, CHARACTER_MAXIMUM_LENGTH, CHARACTER_OCTET_LENGTH, NUMERIC_PRECISION, NUMERIC_SCALE, CHARACTER_SET_NAME, and COLLATION_NAME.

This change produces an incompatibility for applications that depend on column order in the ROUTINES table because the new columns appear between the ROUTINE_TYPE and DTD_IDENTIFIER columns. Such applications may need to be adjusted to account for the new columns.

Important Change: Replication: RESET MASTER and RESET SLAVE now reset the values shown for Last_IO_Error, Last_IO_Errno, Last_SQL_Error, and Last_SQL_Errno in the output of SHOW SLAVE STATUS. (Bug#34654)

See also Bug#44270.

Important Change: The --skip-thread-priority option is now deprecated such that the server won't change the thread priorities by default. Giving threads different priorities might yield marginal improvements in some platforms (where it actually works), but it might instead cause significant degradation depending on the thread count and number of processors. Meddling with the thread priorities is a not a safe bet as it is very dependent on the behavior of the CPU scheduler and system where MySQL is being run. (Bug#35164, Bug#37536)

Cluster Replication: Replication: MySQL Replication now supports attribute promotion and demotion for row-based replication between columns of different but similar types on the master and the slave. For example, it is possible to promote an INT column on the master to a BIGINT column on the slave, and to demote a TEXT column to a VARCHAR column.

The implementation of type demotion distinguishes between lossy and non-lossy type conversions, and their use on the slave can be controlled by setting the slave_type_conversions global server system variable.

For more information, see Row-based replication: attribute promotion and demotion. (Bug#47163, Bug#46584)

Replication: For replication based on row-based and mix-format binary logging, it is now safe to mix transactional and nontransactional statements within a transaction. The nontransactional statements are logged immediately rather than waiting until the transaction ends, ensuring that their results are logged and replicated correctly regardless of the result of the transaction.

mysqltest has a new --max-connections option to set a higher number of maximum permitted server connections than the default 128. This option can also be passed using mysql-test-run.pl. (Bug#51135)

mysql-test-run.pl has a new --portbase option and a corresponding MTR_PORT_BASE environment variable for setting the port range, as an alternative to the existing --build-thread option. (Bug#50182)

SHOW PROFILE CPU has been ported to Windows. Thanks to Alex Budovski for the patch. (Bug#50057)

mysql-test-run.pl has a new --gprof option that runs the server through the gprof profiler, much the same way the currently supported --gcov option runs it through gcov. (Bug#49345)

mysqltest has a new lowercase_result command that converts the output of the next statement to lowercase. This is useful for test cases where the lettercase may vary between platforms. (Bug#48863)

mysqltest has a new remove_files_wildcard command that removes files matching a pattern from a directory. (Bug#39774)

MySQL support for adding collations using LDML specifications did not support the <i> identity rule that indicates one character sorts identically to another. The <i> rule now is supported. (Bug#37129)

For boolean options, the option-processing library now prints additional information in the --help message: If the option is enabled by default, the message says so and indicates that the --skip form of the option disables the option. This affects all compiled MySQL programs that use the library. (Bug#35224)

The use of the SQL_CACHE and SQL_NO_CACHE options in SELECT statements now is checked more restrictively: 1) Previously, both options could be given in the same statement. This is no longer true; only one can be given. 2) Previously, these options could be given in SELECT statements that were not at the top-level. This is no longer true; the options are not permitted in subqueries (including subqueries in the FROM clause, and SELECT statements in unions other than the first SELECT. (Bug#35020)

Added the --auto-vertical-output option to mysql which causes result sets to be displayed vertically if they are too wide for the current window, and using normal tabular format otherwise. (This applies to statements terminated by ; or \G.) (Bug#26780)

TRUNCATE TABLE now is permitted for a table for which a WRITE lock has been acquired with LOCK TABLES. (Bug#20667)

See also Bug#46452.

FLUSH LOGS now takes an optional log_type value so that FLUSH log_type LOGS can be used to flush only a specified log type. These log_type options are permitted:

Thanks to Eric Bergen for the patch to implement this feature. (Bug#14104)

Previously, prepared CALL statements could be used through the C API only for stored procedures that produce at most one result set, and applications could not use placeholders for OUT or INOUT parameters. For prepared CALL statements used using PREPARE and EXECUTE, placeholders could not be used for OUT or INOUT parameters.

For the C API, prepared CALL support now is expanded in the following ways:

For PREPARE and EXECUTE, placeholder support for OUT and INOUT parameters is now available. See Section 12.2.1, “CALL Syntax”. (Bug#11638, Bug#17898)

MySQL now supports IPv6 connections to the local host, using the address ::1. For example:

shell> mysql -h ::1

The address ::1 can be specified in account names in statements such as CREATE USER, GRANT, and REVOKE. For example:

mysql> CREATE USER 'bill'@'::1' IDENTIFIED BY 'secret';
mysql> GRANT SELECT ON mydb.* TO 'bill'@'::1';

The default set of accounts created during MySQL installation now includes an account for 'root'@'::1'.

See Section 5.4.3, “Specifying Account Names”, and Section 2.12.2, “Securing the Initial MySQL Accounts”. (Bug#8836)

Three options were added to mysqldump make it easier to generate a dump from a slave server:

(Bug#8368)

mysqladmin now permits the password value to be omitted following the password command. In this case, mysqladmin prompts for the password value, which enables you to avoid specifying the password on the command line. Omitting the password value should be done only if password is the final command on the mysqladmin command line. Otherwise, the next argument is taken as the password. (Bug#5724)

The optimizer_switch system variable has a new engine_condition_pushdown flag to control whether storage engine condition pushdown optimization is used. The engine_condition_pushdown system variable now is deprecated.

The server now provides a pluggable audit interface that enables information about server operations to be reported to interested parties. Audit plugins may register with the audit interface to receive notification about server operations. When an auditable event occurs within the server, the server determines whether notification is needed. For each registered audit plugin, the server checks the event against those event classes in which the plugin is interested and passes the event to the plugin if there is a match. For more information, see Section 23.2.3.5, “Audit Plugins”.

Some conversions between Japanese character sets are more efficient.

When the server detects MyISAM table corruption, it now writes additional information to the error log, such as the name and line number of the source file, and the list of threads accessing the table. Example: Got an error from thread_id=1, mi_dynrec.c:368. This is useful information to include in bug reports.

The TABLESPACES table has been added to INFORMATION_SCHEMA for tracking tablespace details.

Added the PARAMETERS table to INFORMATION_SCHEMA. The PARAMETERS table provides information about stored procedure and function parameters, and about return values for stored functions.

The maximum length of table comments was extended from 60 to 2048 characters. The maximum length of column comments was extended from 255 to 1024 characters. Index definitions now can include a comment of up to 1024 characters.

Performance: Replication: When writing events to the binary log, transactional events (that is, events that operate on transactional tables) are written to a thread-specific transaction cache, which is then written to the binary log on commit. To handle nontransactional events, there was a lock taken on the binary log (when entering the function MYSQL_BIN_LOG::write()), even when the event was written to the transaction cache instead of the binary log, causing a major bottleneck in replication performance. (Bug#42757)

Security Fix: The server crashed if an account with the CREATE ROUTINE privilege but not the EXECUTE privilege attempted to create a stored procedure. (Bug#44798)

Security Enhancement: When the DATA DIRECTORY or INDEX DIRECTORY clause of a CREATE TABLE statement referred to a subdirectory of the data directory through a symlinked component of the data directory path, it was accepted, when for security reasons it should be rejected. (Bug#39277)

Incompatible Change: Replication: The --binlog_format system variable can no longer be set inside a transaction. In other words, the binary logging format can no longer be changed while a transaction is in progress. (Bug#47863)

Incompatible Change: For debug builds, wttempts to execute RESET statements within a transaction that had acquired metadata locks led to an assertion failure.

As a result of this bug fix, RESET statements now cause an implicit commit. (Bug#51336)

Incompatible Change: A deadlock occurred for this sequence of events: Session 1 locked a table using LOCK TABLES; Session 2 dropped the database containing the table; Session 1 created any database.

A consequence of this bug fix is that CREATE DATABASE is not permitted within a session that has an active LOCK TABLES statement. (Bug#49988)

Incompatible Change: CREATE TABLE statements (including CREATE TABLE ... LIKE) are now prohibited whenever a LOCK TABLES statement is in effect. (Bug#42546)

Incompatible Change: For application compatibility reasons, when sql_auto_is_null is 1, MySQL converts auto_inc_col IS NULL to auto_inc_col = LAST_INSERT_ID(). However, this was being done regardless of whether the predicate was alone or at the top level. Now it occurs only when it is a single top-level predicate.

In conjunction with this bug fix, the default value of the sql_auto_is_null system variable has been changed from 1 to 0, which may cause incompatibilities with existing applications. (Bug#41371)

Incompatible Change: The parser accepted illegal syntax in a FOREIGN KEY clause:

These illegal syntaxes are now properly rejected. Existing applications that used them will require adjustment. (Bug#34455)

Incompatible Change: The parser accepted an INTO clause in nested SELECT statements, which is invalid because such statements must return their results to the outer context. This syntax is no longer permitted. (Bug#33204)

Incompatible Change: The Locked thread state was equivalent to the Table lock state and has been removed. It no longer appears in SHOW PROCESSLIST output. (Bug#28870)

Incompatible Change: Several changes were made to alias resolution in multiple-table DELETE statements so that it is no longer possible to have inconsistent or ambiguous table aliases.

Statements containing alias constructs that are no longer permitted must be rewritten. (Bug#27525)

See also Bug#30234.

Incompatible Change: DROP TABLE now is permitted only if you have acquired a WRITE lock with LOCK TABLES, or if you hold no locks, or if the table is a TEMPORARY table.

Previously, if other tables were locked, you could drop a table with a read lock or no lock, which could lead to deadlocks between clients. The new stricter behavior means that some usage scenarios will fail when previously they did not. (Bug#25858)

Incompatible Change: If a data definition language (DDL) statement occurred for a table that was being used by another session in an active transaction, statements could be written to the binary log in the wrong order. For example, this could happen if DROP TABLE occurred for a table being used in a transaction. This is now prevented by deferring release of metadata locks on tables used within a transaction until the transaction ends.

This bug fix results in some incompatibilities with previous versions:

(Bug#989, Bug#39675)

Important Change: Replication: For an engine that supported only row-based replication, replication stopped with an error when executing row events.

For information about changes in how the binary logging format is determined in relation to statement type and storage engine logging capabilities, see Section 5.2.4.3, “Mixed Binary Logging Format”.

As part of the fix for this issue, the EXAMPLE storage engine is now changed so that it supports statement-based logging only. Previously, it supported row-based logging only. (Bug#39934)

Important Change: The IPv6 loopback address ::1 was interpeted as a hostname rather than a numeric IP address.

In addition, the IPv6-enabled server on Windows interpeted the hostname localhost as ::1 only, which failed to match the default 'root'@'127.0.0.1' account in the mysql.user privilege table.

(Bug#43006)

See also Bug#38247, Bug#45283, Bug#45584, Bug#45606.

InnoDB Storage Engine: Replication: Column length information generated by InnoDB did not match that generated by MyISAM, which caused invalid metadata to be written to the binary log when trying to replicate BIT columns. (Bug#49618)

InnoDB Storage Engine: SHOW INNODB STATUS could display incorrect information about deadlocks, when the deadlock detection routine stops early (to avoid excessive CPU usage). (Bug#49001)

InnoDB Storage Engine: Concurrent execution of ALTER TABLE for InnoDB table and a transaction that tried to read and then update the table could result in a deadlock between table-level locks and InnoDB row locks, which was detected only after the innodb_lock_wait_timeout timeout occurred. (Bug#37346)

Partitioning: When using a debug build of MySQL, if a query against a partitioned table having an index on one or more DOUBLE columns used that index, the server failed with an assertion. (Bug#45816)

Partitioning: The first time that a query against the INFORMATION_SCHEMA.TABLES table for partitioned tables using the ARCHIVE engine was run, it returned invalid data. If the server had been restarted since such a table had been created, or if the table had never actually been opened, its DATA_LENGTH was reported as 0 bytes. (The second and subsequent attempts to issue the same query returned the expected result.) (Bug#44622)

Partitioning: ALTER TABLE on a partitioned table caused unnecessary deadlocks. (Bug#43867)

See also Bug#46654.

Partitioning: Attempting to drop a partitioned table from one connection while waiting for the completion of an ALTER TABLE that had been issued from a different connection, and that changed the storage engine used by the table, could cause the server to crash. (Bug#42438)

Partitioning: After attempting to create a duplicate index on a partitioned table (and having the attempt fail as expected), a subsequent attempt to create a new index on the table caused the server to hang. (Bug#40181)

Partitioning: When used on a partitioned table, ALTER TABLE produced the wrong error message when the name of a nonexistent storage engine was used in the ENGINE clause. (Bug#35765)

Partitioning: When one user was in the midst of a transaction on a partitioned table, a second user performing an ALTER TABLE on this table caused the server to hang. (Bug#34604)

Partitioning: Portions of the partitioning code were refactored in response to potential regression issues uncovered while working on the fix for Bug#31210. (Bug#32115)

See also Bug#40281.

Replication: When using the row-based or mixed replication format with a debug build of the MySQL server, inserts into columns using the UTF32 character set on the master caused the slave to crash. (Bug#51787)

See also Bug#51716.

Replication: When using the row-based or mixed replication format, column values using the UTF16 character set on the master were padded incorrectly on the slave. (Bug#51716)

See also Bug#51787.

Replication: An issue internal to the code, first seen in Bug#49132 but not completely resolved in the fix for that bug, was removed. This should prevent similar issues to those in the previous bug with binlog_format changes following DDL statements.

For developers working with the MySQL Server code: the public class variable THD::current_stmt_binlog_row_based was supposed to have been removed as part of the fix for Bug#39934, but was still present in the code. If a developer later tried to use this variable, it could cause the previous issues to re-occur, and possibly new ones to arise. The variable has now been removed; the previously added class functions THD::is_current_stmt_binlog_format_row(), THD::set_current_stmt_binlog_format_row(), and THD::clear_current_stmt_binlog_format_row() should be used instead. (Bug#51021)

Replication: Adding an index to a table on the master caused the slave to stop logging slow queries to the slow query log. (Bug#50620)

Replication: If a CHANGE MASTER TO statement set MASTER_HEARTBEAT_PERIOD to 30 or higher, Slave_received_heartbeats did not increase on the slave. This caused the slave to reconnect before the time indicated by slave_net_timeout had elapsed.

This issue affected big-endian 64-bit platforms such as Solaris/SPARC. (Bug#50296)

Replication: The error message given when trying to replicate (using statement-based mode) insertions into an AUTO_INCREMENT column by a stored function or a trigger was improved. (Bug#50192)

Replication: The server could deadlock when FLUSH LOGS was executed concurrently with DML statements. To fix this problem, nontransactional changes are now always flushed before transactional changes. (Bug#50038)

Replication: Metadata for GEOMETRY fields was not properly stored by the slave in its definitions of tables. (Bug#49836)

See also Bug#48776.

Replication: Statement-based replication of user variables having numeric data types did not always work correctly. (Bug#49562)

Replication: When using the semi-synchronous replication plugin on Windows, the wait time calculated when the master was waiting for reply from the slave was incorrect. In addition, when the wait time was less than the current time, the master did not wait for a reply at all.

This issue was caused by the fact that a different internal function was used to get current time by the plugin on Windows as opposed to other platforms, and this function was not correctly implemented. Now the Windows version of the plugin uses the same function as other platforms for this purpose. (Bug#49557)

Replication: Due to a change in the format of the information used by the slave to connect to the master, which could cause to reject connection attempts to older masters by newer slaves. (Bug#49259)

This regression was introduced by Bug#13963.

Replication: When using row-based logging, a failing INSERT...SELECT statement on a nontransactional table was not flagged correctly, such that, if a rollback was requested and no other nontransactional table had been updated, nothing was written to the binary log. (Bug#47175)

See also Bug#40278.

Replication: When using row-based replication, the incomplete logging of a group of events involving both transaction and nontransactional tables could cause STOP SLAVE to hang. (Bug#45940)

See also Bug#319, Bug#38205.

Replication: There were two related issues concerning handling of unsafe statements and setting of the binary logging format when there were open temporary tables on the master, and the existing replication format was row-based or mixed:

(Bug#45855, Bug#45856)

Replication: Statements that updated AUTO_INCREMENT columns in multiple tables were logged using the row-based format when --binlog_format was set to MIXED, but did not cause an Unsafe statement warning to be generated when --binlog_format was set to STATEMENT. (Bug#45827)

See also Bug#39934.

Replication: Even though INSERT DELAYED statements are unsafe for statement-based replication, they caused the statement only to be logged in row format when the binary logging format was MIXED, but did not cause a warning to be generated when the binary logging format was STATEMENT. (Bug#45825)

Replication: When using MIXED binary logging format, statements containing a LIMIT clause and occurring in stored routines were not written to the log as row events. (Bug#45785)

Replication: When using statement-based replication, database-level character sets were not always honored by the replication SQL thread. This could cause data inserted on the master using LOAD DATA to be replicated using the wrong character set.

(Bug#45516)

Replication: STOP SLAVE did not flush the relay log or the master.info or relay-log.info files, which could lead to corruption if the server crashed. (Bug#44188)

Replication: Large transactions and statements could corrupt the binary log if the size of the cache (as set by max_binlog_cache_size) was not large enough to store the changes.

Now, for transactions that do not fit into the cache, the statement is not logged, and the statement generates an error instead.

For nontransactional changes that do not fit into the cache, the statement is also not logged—an incident event is logged after committing or rolling back any pending transaction, and the statement then raises an error.

(Bug#43929)

See also Bug#37148.

Replication: On Windows, RESET MASTER failed in the event of a missing binlog file rather than issuing a warning and completing the rest of the statement. (Bug#42150, Bug#42218)

Replication: Executing the sequence of statements RESET SLAVE, RESET MASTER, and FLUSH LOGS, when binary log or relay log files listed in the index file could not be found, could cause the server to crash. This could happen, for example, when these files had been moved or deleted manually. (Bug#41902)

Replication: MySQL creates binary logs in a numbered sequence, with a maximum possible 4294967295 concurrent log files, 4294967295 being the maximum value for an unsigned long integer. However, binary log file extensions were turned into negative numbers once the variable used to hold the value reached the maximum value for a signed long integer (2147483647). Consequently, when the sequence value was incremented to the next (negative) number, this caused MySQL to try to create the file using a .000000 extension, causing the server to fail since this file already existed.

Negative file extensions are no longer permitted, and an error is returned when the limit is reached. In addition, FLUSH LOGS now also reports warnings to the user, if the extension number has reached the limit, and warnings are printed to the error log when the limit is approaching. (Bug#40611)

Replication: Issuing concurrent STOP SLAVE, START SLAVE, and RESET SLAVE statements using different connections caused the replication slave to crash. (Bug#38716)

See also Bug#38715, Bug#44312.

Replication: A slave compiled using --with-libevent and run with --thread-handling=pool-of-threads could sometimes crash. (Bug#36929)

Replication: mysqlbinlog sometimes failed when trying to create temporary files; this was because it ignored the specified temp file directory and tried to use the system /tmp directory instead. (Bug#35546)

See also Bug#35543.

Replication: A CHANGE MASTER TO statement with no MASTER_HEARTBEAT_PERIOD option failed to reset the heartbeat period to its default value. (Bug#34686)

Replication: Concurrent statements using a stored function and DROP FUNCTION for that function could break statement-based replication. (Bug#30977)

See also Bug#57663.

Replication: As part of the fix for this issue, the Rpl_recovery_rank column, which had appeared in the output of SHOW SLAVE HOSTS in some MySQL releases, was removed because the corresponding server variable rpl_recovery_rank (now deprecated) was never actually used. (Bug#13963)

See also Bug#21132, Bug#21869.

mysqld_safe did not pass the correct default value of plugin_dir to mysqld. (Bug#51938)

mysqld_multi failed due to a syntax error in the script. (Bug#51468)

ALTER TABLE on a MERGE table that has been locked using LOCK TABLES ... WRITE incorrectly produced an ER_TABLE_NOT_LOCKED_FOR_WRITE error. (Bug#51240)

The mysql could default to the ascii character set, which is not a valid character set choice for MySQL. The latin1 character set will now be used when an ASCII environment has been identified. (Bug#51166)

On some Unix/Linux platforms, an error during build from source could be produced, referring to a missing LT_INIT program. This is due to versions of libtool 2.1 and earlier. (Bug#51009)

Referring to a subquery result in a HAVING clause could produce incorrect results. (Bug#50995)

Aggregate functions on TIMESTAMP columns could yield incorrect or undefined results. (Bug#50888)

Use of filesort plus the join cache normally is preferred to a full index scan. But it was used even if the index is clustered, in which case, the clustered index scan can be faster. (Bug#50843)

For debug builds, SHOW BINARY LOGS caused an assertion to be raised if binary logging was not enabled. (Bug#50780)

The server did not recognize that the stored procedure cache became invalid if a view was created or modified within a procedure, resulting in a crash. (Bug#50624)

Incorrect handling of BIT columns in temporary tables could lead to spurious duplicate-key errors. (Bug#50591)

The second or subsequent invocation of a stored procedure containing DROP TRIGGER could cause a server crash. (Bug#50423)

The return value for calls to put information into the stored routine cache were not consistently checked, causing an assertion to be raised. (Bug#50412)

Full-text queries that used the truncation operator (*) could enter an infinite loop. (Bug#50351)

For debug builds, an assertion was incorrectly raised in the optimizer when matching ORDER BY expressions. (Bug#50335)

Queries optimized with GROUP_MIN_MAX did not clean up KEYREAD optimizations properly, causing subsequent queries to return incomplete rows. (Bug#49902)

mysql --show-warnings crashed if the server connection was lost. (Bug#49646)

For string-valued system variables containing multibyte characters, the byte length was used in contexts where the character length was more appropriate. (Bug#49645)

SHOW VARIABLES did not correctly display string-valued system variables that contained \0 characters. (Bug#49644)

MySQL program option-processing code incorrectly displayed some options when printing ambiguous-option errors. (Bug#49640)

For dynamic format MyISAM tables containing LONGTEXT columns, a bulk INSERT ... ON DUPLICATE KEY UPDATE or bulk REPLACE could cause corruption. (Bug#49628)

Setting binlog_format to DEFAULT assigned a value different from the default. (Bug#49540)

For debug builds, with sql_safe_updates enabled, a multiple-table UPDATE with the IGNORE modifier could raise an assertion. (Bug#49534)

EXPLAIN EXTENDED crashed trying to print column names for a subquery in the FROM clause when the table had gone out of scope. (Bug#49487)

For InnoDB tables, the test for using an index for ORDER BY sorting did not distinguish between primary keys and secondary indexes and expected primary key values to be concatenated to index values the way they are to secondary key values. (Bug#49324)

mysqltest no longer lets you execute an SQL statement on a connection after doing a send command, unless you do a reap first. This was previously accepted but could produce unpredictable results. (Bug#49269)

Valgrind warnings for several logging messages were corrected. (Bug#49130)

For debug builds on Windows, warnings about incorrect use of debugging directives were written to the error log. The directives were rewritten to eliminate these messages. (Bug#49025)

Plugins in a binary release could not be installed into a debug version of the server. (Bug#49022)

On POSIX systems, calls to select() with a file descriptor set larger than FD_SETSIZE resulted in unpredictable I/O errors; for example, when a large number of tables required repair. (Bug#48929)

A dependent subquery containing COUNT(DISTINCT col_name)) could be evaluated incorrectly. (Bug#48920)

If a stored function contained a RETURN statement with an ENUM value in the ucs2 character set, SHOW CREATE FUNCTION and SELECT DTD_IDENTIFIER FROM INFORMATION_SCHEMA.ROUTINES returned incorrect values. (Bug#48766)

An ARZ file missing from the database directory caused the server to crash. (Bug#48757)

Running SHOW CREATE TABLE on a view v1 that contained a function which accessed another view v2 could trigger a infinite loop if the view (v2) referenced within the function caused a warning to be raised while being opened. (Bug#48449)

Invalid memory reads could occur following a query that referenced a MyISAM tale multiple times with a write lock. (Bug#48438)

For debug builds, creating a view containing a row constructor caused an assertion to be raised. (Bug#48294)

An aliasing violation in the C API could lead to a crash. (Bug#48284)

Slow CALL statements were not always logged to the slow query log because execution time for multiple-statement stored procedures was assessed incorrectly. (Bug#47905)

For debug builds, killing a SELECT retrieving from a view that was processing a function caused an assertion to be raised. (Bug#47736)

Failure to open a view with a nonexistent DEFINER was improperly handled and the server would crash later attempting to lock the view. (Bug#47734)

If a prepared statement used both a MERGE table and a stored function or trigger, execution sometimes failed with a No such table error. (Bug#47648)

CREATE VIEW raised an assertion if a temporary table existed with the same name as the view. (Bug#47635)

If a temporary table was created with the same name as a view referenced in a stored routine, routine execution could raise an assertion. (Bug#47313)

Selecting from the process list in the embedded server caused a crash. (Bug#47304)

See also Bug#43733.

Programs did not exit if the option file specfied by --defaults-file was not found. (Bug#47216)

Attempts to print octal numbers with my_vsnprintf() could cause a crash. (Bug#47212)

Corrected a potential problem of unintended overwriting of files when the MY_DONT_OVERWRITE_FILE flag was used. (Bug#47126)

Deadlock occurred if one session was running a multiple-statement transaction that involved a single partitioned table and another session attempted to alter the table. (Bug#46654)

Valgrind warnings about memory allocation overruns for handling CREATE FUNCTION statements for UDFs were corrected. (Bug#46570)

The server could crash attempting to flush privileges after receipt of a SIGHUP signal. (Bug#46495)

If INSERT INTO tbl_name invoked a stored function that modified tbl_name, the server crashed. (Bug#46374)

For queries that used GROUP_CONCAT(DISTINCT ...), the value of max_heap_table_size was used for memory allocation, which could be excessive. Now the minimum of max_heap_table_size and tmp_table_size is used. (Bug#46018)

Improperly closing tables when INSERT DELAYED needed to reopen tables could cause an assertion failure. (Bug#45949)

See also Bug#18484.

Grouping by a subquery in a query with a DISTINCT aggregate function led to incorrect and unordered grouping values. (Bug#45640)

For an IPv6-enabled MySQL server, privileges specified using standard IPv4 addresses for hosts were not matched (only IPv4-mapped addresses were handled correctly).

As part of the fix for this bug, a new build option --disable-ipv6 has been introduced. Compiling MySQL with this option causes all IPv6-specific code in the server to be ignored.

(Bug#45606)

See also Bug#38247, Bug#43006, Bug#45283, Bug#45584.

The hostname cache failed to work correctly. (Bug#45584)

See also Bug#38247, Bug#43006, Bug#45283, Bug#45606.

A Windows Installation using the GUI installer would fail with:

MySQL Server 5.1 Setup Wizard ended prematurely

The wizard was interrupted before MySQL Server 5.1. could be completely installed.

Your system has not been modified. To complete installation at another time, please run
setup again.

Click Finish to exit the wizard

This was due to an step in the MSI installer that could fail to execute correctly on some environments. (Bug#45418)

Propagation of a large unsigned numeric constant in WHERE expressions could lead to incorrect results. This also affected EXPLAIN EXTENDED, which printed incorrect numeric constants in such transformed WHERE expressions. (Bug#45360)

There was no timeout for attempts to acquire metadata locks (for example, a DROP TABLE attempt for a table that was open in another transaction would not time out).

To handle such situations, there is now a lock_wait_timeout system variable that specifies the timeout in seconds for attempts to acquire metadata locks. The permitted values range from 1 to 3153600 (1 year). The default is 3153600.

This timeout applies to all statements that use metadata locks. These include DML and DDL operations on tables, views, stored procedures, and stored functions, as well as LOCK TABLES, FLUSH TABLES WITH READ LOCK, and HANDLER statements.

The timeout value applies separately for each metadata lock attempt. A given statement can require more than one lock, so it is possible for the statement to block for longer than the lock_wait_timeout value before reporting a timeout error. When lock timeout occurs, ER_LOCK_WAIT_TIMEOUT is reported.

lock_wait_timeout does not apply to delayed inserts, which always execute with a timeout of 1 year. This is done to avoid unnecessary timeouts because a session that issues a delayed insert receives no notification of delayed insert timeouts.

In addition, the unused table_lock_wait_timeout system variable was removed. (Bug#45225)

Valgrind warnings about uninitialized variables in optimizer code were corrected. (Bug#45195)

Killing a delayed-insert thread could cause a server crash. (Bug#45067)

Execution of FLUSH TABLES or FLUSH TABLES WITH READ LOCK concurrently with LOCK TABLES resulted in deadlock. (Bug#45066)

The mysql_real_connect() C API function only attempted to connect to the first IP address returned for a hostname. This could be a problem if a hostname mapped to multiple IP address and the server was not bound to the first one returned. Now mysql_real_connect() attempts to connect to all IPv4 or IPv6 addresses that a domain name maps to. (Bug#45017)

See also Bug#47757.

For plugins that did not have command-line options other than the ones to select the plugin itself, those options were not displayed in the mysqld help message. (Bug#44797)

Some plugins configured as mandatory could be disabled at server startup. (Bug#44691)

InnoDB took a shared row lock when executing SELECT statements inside a stored function as a part of a transaction using REPEATABLE READ. This prevented other transactions from updating the row. (Bug#44613)

MySQL Server permitted the creation of a merge table based on views but crashed when attempts were made to read from that table. The following example demonstrates this:

#Create a test table
CREATE TABLE tmp (id int, c char(2));                                           

#Create two VIEWs upon it
CREATE VIEW v1 AS SELECT * FROM tmp;                                            
CREATE VIEW v2 AS SELECT * FROM tmp;                                            

#Finally create a MERGE table upon the VIEWs
CREATE TABLE merge (id int, c char(2))
ENGINE=MERGE UNION(v1, v2);

#Reading from the merge table lead to a crash
SELECT * FROM merge;

The final line of the code generated the crash. (Bug#44040)

A natural join of INFORMATION_SCHEMA tables could cause an assertion failure. (Bug#43834)

When used in conjunction with LOCK TABLES, FLUSH TABLE tbl_list waited for all tables with old versions to clear from the table definition list, rather than only the named tables. (Bug#43685)

HANDLER statements are now not permitted if a table lock has been acquired with LOCK TABLES. (Bug#43272)

In the embedded server, stack overflow checks for recursive stored procedure calls did not work and stack overflow could occur. (Bug#43201)

The server could crash if an attempt to open a MERGE table child MyISAM table failed. (Bug#42862)

Comparison of TIME values could lose the sign of operands. (Bug#42664)

MAKETIME() could lose the sign of negative arguments. (Bug#42662)

SEC_TO_TIME() could lose the sign of negative arguments. (Bug#42661)

Due to work done for Bug#989, FLUSH TABLES is not permitted when there is an active LOCK TABLES ... READ. This caused a problem with mysqlhotcopy, which used that sequence of statements. mysqlhotcopy now uses FLUSH TABLES tbl_list WITH READ LOCK to flush and lock tables. If mysqlhotcopy is used with a server older than MySQL 5.5.3 that does not support this statement, it has a new option --old_server that causes it to use the previous statement sequence. (Bug#42465)

Setting key_buffer_size to a negative value could lead to very large allocations. Now an error occurs. (Bug#42103)

An assertion failure could occur if OPTIMIZE TABLE was started on an InnoDB table and the table was altered to a different storage engine during the optimization operation. (Bug#42074)

The state of a thread for the embedded server was always displayed as Writing to net, which is incorrect because there is no network connection for the embedded server. (Bug#41971)

The patch for Bug#10374 broke named-pipe and shared-memory connections on Windows. (Bug#41860)

Purging the stored routine cache could take a long time and render the server unresponsive. (Bug#41804)

Command-line options for enumeration-type plugin variables were not honored. (Bug#41010)

System variables could be set to invalid values. (Bug#40988)

The CSV storage engine did not parse '\X' characters when they occurred in unquoted fields. (Bug#40814)

When archive tables were joined on their primary keys, a query returned no result if the optimizer chose to use this index. (Bug#40677)

mysqld_safe did not treat dashes and underscores as equivalent in option names. Thanks to Erik Ljungstrom for the patch to fix this bug. (Bug#40368)

SHOW CREATE VIEW returned invalid SQL if the definition contained a SELECT 'string' statement where the string was longer than the maximum length of a column name, due to the fact that this text was also used as an alias (in the AS clause).

Because not all names retrieved from arbitrary SELECT statements can be used as view column names due to length and format restrictions, the server now checks the conformity of automatically generated column names and rewrites according to a predefined format any names that are not acceptable as view column names before storing the final view definition on disk.

In such cases, the name is now rewritten as Name_exp_pos, where pos is the position of the column. To avoid this conversion scheme, define explicit, valid names for view columns using the column_list clause of the CREATE VIEW statement.

As part of this fix, aliases are now generated only for top-level statements. (Bug#40277)

Threads were set to the Table lock state in such a way that use of this state by other threads to check for a lock wait was subject to a race condition. (Bug#39897)

Plugin shutdown could lead to an assertion failure caused by using an already destroyed mutex in the metadata locking subsystem. (Bug#39674)

Dropping a locked Maria table leads to an assertion failure. (Bug#39395)

Host name lookup failure could lead to a server crash. (Bug#39153)

flush_cache_records() did not correctly check for errors that should cause statement execution to stop, leading to a server crash. (Bug#39022)

InnoDB logged an error repeatedly trying to load a page into the buffer pool, filling the error log and using excessive disk space. Now the number of attempts is limited to 100, after which the operation aborts with a message. (Bug#38901)

Valgrind warnings that occurred for SHOW TABLE STATUS with InnoDB tables were silenced. (Bug#38479)

An IPv6-enabled MySQL server did not resolve the IP addresses of incoming connections correctly, with the result that a connection that attempted to match any privilege table entries using fully-qualified domain names for hostnames or hostnames using wildcards were dropped. (Bug#38247)

See also Bug#43006, Bug#45283, Bug#45584, Bug#45606.

For CREATE TABLE ... LIKE with a MERGE source table that included a UNION clause, that clause was omitted from the definition of the destination table. (Bug#37371)

Previously, statements inside a stored program did not clear the warning list. For example, warnings or errors generated by statements within a trigger or stored function would be accumulated and added to the message list for the statement that activated the trigger or invoked the function, “polluting” the output of SHOW WARNINGS or SHOW ERRORS for the outer statement. Normally, messages for a statement that can generate messages replace messages from the previous such statement. The effect was that a statement could have a different effect on the message list depending on whether it executed inside or outside of a stored program.

Now within a stored program, successive statements that can generate messages update the message list and replace messages from the previous such statement. Only messages from the last of these statements is copied to the message list for the outer statement. (Bug#36649)

myisampack --join did not create the destination table .frm file. (Bug#36573)

The parser incorrectly permitted MySQL error code 0 to be specified for a condition handler. (This is incorrect because the condition must be a failure condition and 0 indicates success.) (Bug#36510)

When parsing or formatting interval values of DAY_MICROSECOND type, fractional seconds were not handled correctly when more-significant fields were implied or omitted. (Bug#36466)

mysql_install_db failed if run as root and the root directory (/) was not writable. (Bug#36462)

mysql_stmt_prepare() did not reset the list of messages (those messages available using SHOW WARNINGS). (Bug#36004)

A global read lock obtained with FLUSH TABLES WITH READ LOCK did not prevent sessions from creating tables. (Bug#35935)

mysqlbinlog left temporary files on the disk after shutdown, leading to the pollution of the temporary directory, which eventually caused mysqlbinlog to fail. This caused problems in testing and other situations where mysqlbinlog might be invoked many times in a relatively short period of time. (Bug#35543)

When building MySQL when using a different target directory (for example using the VPATH environment variable), the build of the embedded readline component would fail. (Bug#35250)

String-valued system variables could be assigned literal values, but could not be assigned values using expressions. Now expressions are legal. (Bug#34883, Bug#46314)

The sql_mode system variable could be assigned the illegal value of '?'. (Bug#34834)

Some system variables could not be assigned the value DEFAULT to assign their default value. (Bug#34829, Bug#34878)

Compiling MySQL on FreeBSD would fail due to missing definitions for certain network constants. (Bug#34292)

Creation of a temporary BLOB or TEXT column could create a column with the wrong maximum length. (Bug#33969)

INSERT INTO ... VALUES(DEFAULT) failed to insert the correct value for ENUM columns. For MyISAM tables, an empty value was inserted. For CSV tables, the table became corrupt. (Bug#33717)

When read_only was enabled, the server incorrectly prevented data modifications to TEMPORARY tables belonging to transactional storage engines such as InnoDB. (Bug#33669)

Constant expressions in WHERE, HAVING, or ON clauses were not cached, but were evaluated for each row. This caused a slowdown of query execution, especially if constant user-defined functions or stored functions were used. (Bug#33546)

Plugins could find the unqualified form of their system variables but not the qualified form. For example, a plugin p with a system variable sv could find sv but not p_sv. (Bug#32902)

Killing a statement that invoked a stored function could return an incorrect error message indicating table corruption rather than that the statement had been interrupted. (Bug#32140)

Occurrence of an error within a stored routine did not always cause immediate statement termination. (Bug#31881)

For DROP FUNCTION db_name.func_name (that is, when the function name is qualified with the database name), the statement should apply only to a stored function named func_name in the given database. However, if a UDF with the same name existed, the statement dropped the UDF instead. (Bug#31767)

mysqld sometimes miscalculated the number of digits required when storing a floating-point number in a CHAR column. This caused the value to be truncated, or (when using a debug build) caused the server to crash. (Bug#26788)

See also Bug#12860.

ALTER TABLE could not be used to add columns to a table if the table had an index on a utf8 column with a TEXT data type. (Bug#26180)

If an operation had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (such as two distinct MyISAM tables), the triggers were unable to execute concurrently. In addition, INSERT and UPDATE statements for the InnoDB table were unable to run concurrently. (Bug#26141)

Some system variables displayed by SHOW VARIABLES could not be selected using SELECT @@{GLOBAL,SESSION}.var_name. (Bug#25430)

Statements to create, alter, or drop a view were not waiting for completion of statements that were using the view, which led to incorrect sequences of statements in the binary log when statement-based logging was enabled. (Bug#25144)

Previously, the server handled character data types for a stored routine parameter, local routine variable created with DECLARE, or stored function return value as follows: If the CHARACTER SET attribute was present, the COLLATE attribute was not supported, so the character set's default collation was used. (This includes use of BINARY, which in this context specifies the binary collation of the character set.) If there was no CHARACTER SET attribute, the database character set and its default collation were used.

Now for character data types, if there is a CHARACTER SET attribute in the declaration, the specified character set and its default collation is used. If the COLLATE is also present, that collation is used rather than the default collation. If there is no CHARACTER SET attribute, the database character set and collation in effect at routine creation time are used. (The database character set and collation are given by the value of the character_set_database and collation_database system variables.) (Bug#24690)

Data truncated for column col_num at row row_num warnings were generated for some (constant) values that did not have too high precision. (Bug#24541)

A statement that caused a circular wait among statements did not return a deadlock error. Now the server detects deadlock and returns ER_LOCK_DEADLOCK. (Bug#22876)

CREATE TABLE ... LIKE did not always produce an error is the source table column defaults were illegal for the current version of MySQL. (This could occur if the table was created using an older server that was less restrictive about legal default values.) (Bug#22090)

Several data-modification statements were not being counted toward the MAX_UPDATES_PER_HOUR user resource limit. (Bug#21793)

When inserting an extraordinarly large value into a DOUBLE column, the value could be truncated in such a way that the new value cannot be reloaded manually or from the output of mysqldump. (Bug#21497)

The value of sql_slave_skip_counter was empty when displayed by SHOW VARIABLES or INFORMATION_SCHEMA.GLOBAL_VARIABLES. (Bug#20413, Bug#37187)

For INSERT DELAYED statements issued for a table while an ALTER TABLE operation on the table was in progress, the server could return a spurious Server shutdown in progress error. (Bug#18484)

See also Bug#45949.

Delayed-insert threads were counted as connected but not as created, incorrectly leading to a Threads_connected value greater than the Threads_created value. (Bug#17954)

The character set was not being properly initialized for CAST() with a type such as CHAR(2) BINARY, which resulted in incorrect results or a server crash. (Bug#17903)

Stored procedure exception handlers were catching fatal errors (such as out of memory errors), which could cause execution not to stop to due a continue handler. Now fatal errors are not caught by exception handlers and a fatal error is returned to the client. (Bug#15192)

Zero-padding of exponent values was not the same across platforms. (Bug#12860)

For CREATE TABLE, the parser did not enforce that parentheses were present in a CHECK (expr) clause; now it does. The parser did not enforce that CONSTRAINT [symbol] without a following CHECK clause was illegal; now it does. (Bug#11714, Bug#35578, Bug#38696)

If a connection was waiting for a GET_LOCK() lock or a SLEEP() call, and the connection aborted, the server did not detect this and thus did not close the connection. This caused a waste of system resources allocated to dead connections. Now the server checks such a connection every five seconds to see whether it has been aborted. If so, the connection is killed (and any lock request is aborted). (Bug#10374)

perror did not work for errors described in the sql/share/errmsg.txt file. (Bug#10143)

The grammar for GROUP BY, when used with WITH CUBE or WITH ROLLUP, caused a conflict with the grammar for view definitions that included WITH CHECK OPTION. (Bug#9801)

For the DIV operator, incorrect results could occur for noninteger operands that exceed BIGINT range. Now, if either operand has a noninteger type, the operands are converted to DECIMAL and divided using DECIMAL arithmetic before converting the result to BIGINT. If the result exceeds BIGINT range, an error occurs. (Bug#8457)

Labels in stored routines did not work if the character set was not latin1. (Bug#7088)

Previously, for some Asian CJK character sets, the UPPER() and LOWER() functions worked only for basic Latin letters (A-Z, a-z). The affected character sets are ujis, sjis, gb2312, cp932, eucjpms, big5, euckr, and gbk.

Now UPPER() and LOWER() perform case conversion correctly for all characters in these character sets, with the exception that if a character set contains a character in only one lettercase, conversion to the other lettercase cannot be done.

This release includes InnoDB 1.0.6. This version is considered of Release Candidate (RC) quality.

Replication: Introduced the binlog_direct_non_transactional_updates system variable. Enabling this variable causes updates using the statement-based logging format to tables using nontransactional engines to be written directly to the binary log, rather than to the transaction cache.

Before enabling this variable, be certain that you have no dependencies between transactional and nontransactional tables. A statement that both selects from an InnoDB table and inserts into a MyISAM table is an example of such a dependency. For more information, see Section 17.1.3.4, “Binary Log Options and Variables”. (Bug#46364)

See also Bug#28976, Bug#40116.

Performance: Partitioning: When used on partitioned tables, the records_in_range handler call checked more partitions than necessary. The fix for this issue reduces the number of unpruned partitions checked for statistics in partition range checking, which has resulted in some partition operations being performed up to 2-10 times faster than before this change was made, when testing with tables having 1024 partitions. (Bug#48846)

See also Bug#37252, Bug#47261.

Performance: The method for comparing INFORMATION_SCHEMA names and database names was nonoptimal and an improvement was made: When the database name length is already known, a length check is made first and content comparison skipped if the lengths are unequal. (Bug#49501)

Performance: The MD5() and SHA1() functions had excessive overhead for short strings. (Bug#49491)

Security Fix: For servers built with yaSSL, a preauthorization buffer overflow could cause memory corruption or a server crash. We thank Evgeny Legerov from Intevydis for providing us with a proof-of-concept script that permitted us to reproduce this bug. (Bug#50227, CVE-2009-4484)

Incompatible Change: In plugin.h, the MYSQL_REPLICATION_PLUGIN symbol was out of synchrony with its value in MySQL 6.0 because the lower-valued MYSQL_AUDIT_PLUGIN was not present. To correct this, MYSQL_AUDIT_PLUGIN has been added in MySQL 5.5, changing the value of MYSQL_REPLICATION_PLUGIN from 5 to 6. Attempts to load the audit plugin produce an error occurs because only the MYSQL_AUDIT_PLUGIN symbol was added, not the audit plugin itself. This error will go away when the audit plugin is added to MySQL 5.5 (in 5.5.3). Replication plugins from earlier 5.5.x releases must be recompiled against the current release before they will work with the current release. (Bug#49894)

Important Change: Replication: The RAND() function is now marked as unsafe for statement-based replication. Using this function now generates a warning when binlog_format=STATEMENT and causes the format to switch to row-based logging when binlog_format=MIXED.

This change is being introduced because, when RAND() was logged in statement mode, the seed was also written to the binary log, so the replication slave generated the same sequence of random numbers as was generated on the master. While this could make replication work in some cases, the order of affected rows was still not guaranteed when this function was used in statements that could update multiple rows, such as UPDATE or INSERT ... SELECT; if the master and the slave retrieved rows in different order, they began to diverge. (Bug#49222)

Partitioning: InnoDB Storage Engine: When an ALTER TABLE ... REORGANIZE PARTITION statement on an InnoDB table failed due to innodb_lock_wait_timeout expiring while waiting for a lock, InnoDB did not clean up any temporary files or tables which it had created. Attempting to reissue the ALTER TABLE statement following the timeout could lead to storage engine errors, or possibly a crash of the server. (Bug#47343)

InnoDB Storage Engine: Creating or dropping a table with 1023 transactions active caused an assertion failure. (Bug#49238)

InnoDB Storage Engine: If innodb_force_recovery was set to 4 or higher, the server could crash when opening an InnoDB table containing an auto-increment column. MySQL versions 5.1.31 and later were affected. (Bug#46193)

Replication: FLUSH LOGS could in some circumstances crash the server. This occurred because the I/O thread could concurrently access the relay log I/O cache while another thread was performing the FLUSH LOGS, which closes and reopens the relay log and, while doing so, initializes (or re-initializes) its I/O cache. This could cause problems if some other thread (in this case, the I/O thread) is accessing it at the same time.

Now the thread performing the FLUSH LOGS takes a lock on the relay log before actually flushing it. (Bug#50364)

See also Bug#53657.

Replication: With semisynchronous replication, memory allocated for handling transactions could be freed while still in use, resulting in a server crash. (Bug#50157)

Replication: In some cases, inserting into a table with many columns could cause the binary log to become corrupted. (Bug#50018)

See also Bug#42749.

Replication: When using row-based replication, setting a BIT or CHAR column of a MyISAM table to NULL, then trying to delete from the table, caused the slave to fail with the error Can't find record in table. (Bug#49481, Bug#49482)

Replication: A LOAD DATA INFILE statement that loaded data into a table having a column name that had to be escaped (such as `key` INT) caused replication to fail when logging in mixed or statement mode. In such cases, the master wrote the LOAD DATA event into the binary log without escaping the column names. (Bug#49479)

See also Bug#47927.

Replication: When logging in row-based mode, DDL statements are actually logged as statements; however, statements that affected temporary tables and followed DDL statements failed to reset the binary log format to ROW, with the result that these statements were logged using the statement-based format. Now the state of binlog_format is restored after a DDL statement has been written to the binary log. (Bug#49132)

Replication: Spatial data types caused row-based replication to crash. (Bug#48776)

Replication: When using row-based logging, the statement CREATE TABLE t IF NOT EXIST ... SELECT was logged as CREATE TEMPORARY TABLE t IF NOT EXIST ... SELECT when t already existed as a temporary table. This was caused by the fact that the temporary table was opened and the results of the SELECT were inserted into it when a temporary table existed and had the same name.

Now, when this statement is executed, t is created as a base table, the results of the SELECT are inserted into it—even if there already exists a temporary table having the same name—and the statement is logged correctly. (Bug#47418)

See also Bug#47442.

Replication: Due to a change in the size of event representations in the binary log, when replicating from a MySQL 4.1 master to a slave running MySQL 5.0.60 or later, the START SLAVE UNTIL statement did not function correctly, stopping at the wrong position in the log. Now the slave detects that the master is using the older version of the binary log format, and corrects for the difference in event size, so that the slave stops in the correct position. (Bug#47142)

Replication: Manually removing entries from the binary log index file on a replication master could cause the server to repeatedly send the same binary log file to slaves. (Bug#28421)

The SSL certificates in the test suite were about to expire. They have been updated with expiration dates in the year 2015. (Bug#50642)

SPATIAL indexes were permitted on columns with non-spatial data types, resulting in a server crash for subsequent table inserts. (Bug#50574)

Index prefixes could be specified with a length greater than the associated column, resulting in a server crash for subsequent table inserts. (Bug#50542)

Use of loose index scan optimization for an aggregate function with DISTINCT (for example, COUNT(DISTINCT)) could produce incorrect results. (Bug#50539)

The printstack function does not exist on Solaris 8 or earlier, which would lead to a compilation failure. (Bug#50409)

A user could see tables in INFORMATION_SCHEMA.TABLES without appropriate privileges for them. (Bug#50276)

Debug output for join structures was garbled. (Bug#50271)

The server crashed when an InnoDB background thread attempted to write a message containing a partitioned table name to the error log. (Bug#50201)

Within a stored routine, selecting the result of CONCAT_WS() with a routine parameter argument into a user variable could return incorrect results. (Bug#50096)

The filesort sorting method applied to a CHAR(0) column could lead to a server crash. (Bug#49897)

EXPLAIN EXTENDED UNION ... ORDER BY caused a crash when the ORDER BY referred to a nonconstant or full-text function or a subquery. (Bug#49734)

Some prepared statements could raise an assertion when re-executed. (Bug#49570)

sql_buffer_result had an effect on non-SELECT statements, contrary to the documentation. (Bug#49552)

In some cases a subquery need not be evaluated because it returns only aggregate values that can be calculated from table metadata. This sometimes was not handled by the enclosing subquery, resulting in a server crash. (Bug#49512)

Mixing full-text searches and row expressions caused a crash. (Bug#49445)

mysql-test-run.pl now recognizes the MTR_TESTCASE_TIMEOUT, MTR_SUITE_TIMEOUT, MTR_SHUTDOWN_TIMEOUT, and MTR_START_TIMEOUT environment variables. If they are set, their values are used to set the --testcase-timeout, --suite-timeout, --shutdown-timeout, and --start-timeout options, respectively. (Bug#49210)

Several strmake() calls had an incorrect length argument (too large by one). (Bug#48983)

On Fedora 12, strmov() did not guarantee correct operation for overlapping source and destination buffer. Calls were fixed to use an overlap-safe version instead. (Bug#48866)