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)