Security Fix; InnoDB: 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. (Bug #54678)

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

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

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 value type and fails with bad geometry value if it detects incorrect parameters. (Bug #55531)

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: 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: Changed the locking mechanism for the InnoDB data dictionary during ROLLBACK operations, to improve concurrency for REPLACE statements. (Bug #54538)

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

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

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

InnoDB: For debug builds, a SELECT ... FOR UPDATE statement affecting a range of rows in an InnoDB table could cause a server crash. (Bug #56716)

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

InnoDB: 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: Setting the PACK_KEYS=0 table option for an InnoDB table prevented new indexes from being added to the table. (Bug #54606)

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: Multiple-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: Backticks used to enclose identifiers 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)

References: See also Bug #55962.

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

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

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)

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)

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

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

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)

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

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, Bug #50774, Bug #11758558)

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

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)

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

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

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 reassigned 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 caused the file descriptor reassignment to fail and the server to abort. To avoid this problem on Windows, the server now first assigns the stdout and stderr streams to the log file stream by opening this file. This causes the 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)

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