MySQL :: MySQL 5.5 Release Notes :: Changes in MySQL 5.5.6 (2010-09-13, Release Candidate)

version 5.5

8.0
5.7 current
5.6

MySQL 5.5 Release Notes / Changes in MySQL 5.5.6 (2010-09-13, Release Candidate)

Changes in MySQL 5.5.6 (2010-09-13, Release Candidate)

Functionality Added or Changed

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)
InnoDB: 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: 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)
REPAIR TABLE and OPTIMIZE TABLE table now catch and throw any errors that occur while copying table statistics from the old corrupted file to newly created file. For example. if the user ID of the owner of the .frm, .MYD, or .MYI file is different from the user ID of the mysqld process, REPAIR TABLE and OPTIMIZE TABLE generate a "cannot change ownership of the file" error unless mysqld is started by the root user. (Bug #61598, Bug #13600058)
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:
- When the MySQL-shared RPM is installed but later it is determined that the MySQL-shared-compat RPM is needed (an application is installed that was linked against an older client library). Installing the MySQL-shared-compat RPM results in a conflict because both include the current library version. This can be overcome by using the --force option to RPM, or by first uninstalling the MySQL-shared RPM (which breaks dependencies).
- When the MySQL-shared-compat RPM is installed, but old applications that require it are removed or upgraded to the current library version. In this case, MySQL-shared-compat cannot be replaced with MySQL-shared as long as current applications are installed. This can be overcome by using the --force option to RPM, which incurs the risk of breaking dependencies.
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)

References: See also: Bug #12368215.
Overhead for the Performance Schema interface was reduced. (Bug #55087)
Within stored programs, LIMIT clauses now permit 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.

Bugs Fixed

Security Fix; InnoDB: 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: 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, Bug #11762026, 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)
Security Fix: A security bug was fixed. (Bug #49124)
Performance; InnoDB: 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: An EXPLAIN plan for an InnoDB table could vary greatly in the estimated cost for a BETWEEN clause. (Bug #53761)
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:
- Previously, for CREATE TABLE IF NOT EXISTS ... SELECT, MySQL produced a warning that the table exists, but inserted the rows and wrote the statement to the binary log anyway. By contrast, CREATE TABLE ... SELECT (without IF NOT EXISTS) failed with an error, but MySQL inserted no rows and did not write the statement to the binary log.
- MySQL now handles both statements the same way when the destination table exists, in that neither statement inserts rows or is written to the binary log. The difference between them is that MySQL produces a warning when IF NOT EXISTS is present and an error when it is not.
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:
- If the destination table does not exist, there is no change: The statement is logged as is.
- If the destination table does exist, the statement is logged as the equivalent pair of CREATE TABLE IF NOT EXISTS and INSERT ... SELECT statements. (If the SELECT in the original statement is preceded by IGNORE or REPLACE, the INSERT becomes INSERT IGNORE or REPLACE, respectively.)
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:
- The SETUP_OBJECTS table was removed.
- The PROCESSLIST table was renamed to THREADS.
- The EVENTS_WAITS_SUMMARY_BY_EVENT_NAME table was renamed to EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME.
(Bug #55416)
Incompatible Change: Handling of warnings and errors during stored program execution was problematic:
- If one statement generated several warnings or errors, only the handler for the first was activated, even if another might be more appropriate. Now the server chooses the more appropriate handler.
- Warning or error information could be lost.
(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: 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: The InnoDB storage engine was not included in the default installation when using the configure script. (Bug #55547)
InnoDB: 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: The mysql_config tool did not output the requirement for the aio library for mysqld-libs. (Bug #55215)
InnoDB: Some memory used for InnoDB asynchronous I/O was not freed at shutdown. (Bug #54764)
InnoDB: 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: 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: 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: 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. If you encounter this message after upgrading, create an InnoDB table with innodb_file_per_table = ON and restart the server. The message should not be displayed any more. If you continue to encounter this message, or if you get it and haven't used a version without this fix, you might have corruption in your shared tablespace. If so, back up and reload your data. (Bug #54658)
InnoDB: For debug builds, the database server could crash when renaming a table that had active transactions. (Bug #54453)
InnoDB: 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: 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: If a session executing TRUNCATE TABLE on an InnoDB table was killed during open_tables(), an assertion could be raised. (Bug #53757)
InnoDB: The Lock_time field in the slow query log now reports a larger value, including the time for InnoDB lock waits at the statement level. (Bug #53496)
InnoDB: Misimplementation of the os_fast_mutex_trylock() function in InnoDB resulted in unnecessary blocking and reduced performance. (Bug #53204)
InnoDB: InnoDB could not create tables that used the utf32 character set. (Bug #52199)
InnoDB: Performing large numbers of RENAME TABLE statements caused excessive memory use. (Bug #47991)
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_ERROR and ER_NO_SUCH_TABLE errors on subsequent attempts. (Bug #53676)

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

References: This issue is a regression of: Bug #39084.
Partitioning: INSERT ON DUPLICATE KEY UPDATE statements performed poorly on tables having many partitions. 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)

References: 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 to ROW, then creating and dropping a temporary table led to an assertion. (Bug #54925)
Replication: When using mixed-format replication, changes made to a nontransactional 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)

References: 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)

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

References: See also: Bug #50364.
Replication: Two related issues involving temporary tables and transactions were introduced by a fix made in MySQL 5.1.37:
1. When a temporary table was created or dropped within a transaction, any failed statement that following the CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE statement triggered a rollback, which caused the slave to diverge from the master.
2. When a CREATE TEMPORARY TABLE ... SELECT * FROM ... statement was executed within a transaction in which only tables using transactional storage engines were used and the transaction was rolled back at the end, the changes—including the creation of the temporary table—were not written to the binary log.
The current fix restores the correct behavior in both of these cases. (Bug #53560)

References: This issue is a regression of: 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)

References: See also: Bug #51894, Bug #53259.
Replication: A number of statements generated unnecessary warnings as potentially unsafe statements. (Due to the fix for Bug #51894, a temporary table is treated in this context as a transactional table, so that any mixed statement such as t_innodb + t_myisam or t_temp + t_myisam is flagged as unsafe.)

To reduce the number of spurious warnings produced when this happened, some of the criteria used to classify a statements as safe or unsafe have been changed. For more information about handling of mixed statements, see Transactional, nontransactional, and mixed statements. (Bug #53259)

References: See also: Bug #51894, Bug #53452, Bug #54872.
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)

References: This issue is a regression of: 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 failed 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)
For the general query log and slow query log, logging to tables incurred excessive overhead beginning with MySQL 5.1.21. This overhead has been eliminated. (Bug #11747038, Bug #30414)

References: See also: Bug #29129.
After an RPM installation, mysqld would be started with the root user, 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 for 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 raise a debug assertion. (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)
The -features=no%except option was missing from the build for Solaris/x86. (Bug #55250)
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 failed during installation to preserve custom settings, such as the configured data directory. (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, the MySQL initialization script is recreated, and the MySQL server is restarted 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)
The 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, and some scripts were built without the execute bit set. (Bug #54466, Bug #54129)
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)
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 raise a debug assertion. (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 statements. (Bug #53737, Bug #53742)

References: See also: Bug #36569.
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 the 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 Performance Schema table resulted in a misleading error message. (Bug #52586)
The ABI check for MySQL failed to compile with gcc 4.5. (Bug #52514)
The 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 I/O events to the same name. (Bug #52134)
PARTITION BY KEY on a utf32 ENUM column raised a debugging assertion. (Bug #52121, Bug #11759782)
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:
- Table lock was replaced with Waiting for table level lock.
- Waiting for table and Flushing tables were replaced with Waiting for table flush.
- These states are new: Waiting for global metadata lock, Waiting for schema metadata lock, Waiting for stored function metadata lock, Waiting for stored procedure metadata lock, Waiting for table metadata lock.
(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 optimization method of the ARCHIVE storage engine did not preserve the .frm file 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 file 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.

Prior to this fix, index hints were accepted for UPDATE statements but were ignored. Now they are used. (Bug #36569)

References: See also: Bug #53737, Bug #53742.

Reading from a temporary MERGE table, with two nontemporary 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)

PREV HOME UP NEXT