Security Fix; InnoDB:
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.
The server crashed for assignment of values of types other than
Geometry to items of type
MultiSurface). Now the server checks the
value type and fails with
bad geometry value
if it detects incorrect parameters.
EXPLAIN EXTENDED caused a server
crash with some prepared statements.
Important Change; Replication:
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
InnoDB incorrectly reported an error when a
cascading foreign key constraint deleted more than 250 rows.
For debug builds, a
SELECT ... FOR UPDATE
statement affecting a range of rows in an
InnoDB table could cause a server crash.
Improved the performance of
InnoDB tables, when only non-indexed
columns are changed.
The server could crash on shutdown, if started with
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
CREATE TABLE statement.
PACK_KEYS=0 table option for an
InnoDB table prevented new indexes
from being added to the table.
Changed the locking mechanism for the
data dictionary during
to improve concurrency for
InnoDB transactions could be incorrectly
committed during recovery, rather than rolled back, if the
server crashed and was restarted after performing
TABLE ... ADD PRIMARY KEY on an
InnoDB table, or some other operation that
involves copying the entire table.
Attempting to execute
on a partitioned
MyISAM table while using
statement-based logging mode caused the master to hang or crash.
involving a partitioned
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.
PARTITIONS returned bad estimates for range queries on
MyISAM tables. In
addition, values in the
rows column of
PARTITIONS output did not take partition pruning into
(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
F encased in
`) characters. If such an ID took
N represents a string of the
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.
References: See also Bug #55962.
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
stderr streams to the file descriptor of
the log file. On Windows, if
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
stderr streams to the log file stream by
opening this file. This causes the
stderr file descriptors to be nonzero and the
server can successfully reassign them to the file descriptor of
the log file.
References: This bug is a regression of Bug #29751.
Memory leaks detected by Valgrind were corrected. (Bug #56709)
If a query specified a
DATETIME value in a format
'YYYY-MM-DD HH:MM:SS', a
matched only greater-than values in an indexed
(Bug #55779, Bug #50774, Bug #11758558)
If there was an active
statement, an error arising during trigger execution could cause
a server crash.
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
Row subqueries producing no rows were not handled as
UNKNOWN values in row-comparison expressions.
max_length metadata value of
MEDIUMBLOB types was reported as
1 byte greater than the correct value.
In some cases, when the left part of a
subquery predicate was a row and contained
NULL values, the query result was incorrect.
For some queries, the optimizer produced incorrect results using
the Index Merge access method with
EXPLAIN produced an incorrect
rows value for queries evaluated using an
index scan and that included
GROUP BY, and
ORDER BY on
a computed column.
mysql_use_result() are not for
use with prepared statements and are not intended to be called
but failed to return an error when invoked that way.
REPAIR TABLE on a
MERGE table caused the
server to crash.
A malformed packet sent by the server when the query cache was in use resulted in lost-connection errors. (Bug #42503)
CREATE TABLE failed if a column
referred to in an index definition and foreign key definition
had different lettercases in the two definitions.