Inserting data of varying record lengths into an
InnoDB table that used
compression could cause
the server to halt with an error.
(Bug #14554000, Bug #13523839, Bug #63815, Bug #12845774, Bug #61456, Bug #12595091, Bug #61208)
Under heavy load of concurrent
DML and queries, an
InnoDB table with a unique index could return
nonexistent duplicate rows to a query.
(Bug #14399148, Bug #66134)
Deleting from an
InnoDB table containing a
prefix index, and
subsequently dropping the index, could cause a crash with an
The error message was improved for the case where an
UPDATE failed because the row
included several BLOB values greater than 768 bytes each,
causing the size of a row to exceed half the
page size. The old
message, was misleading; it suggested using BLOBs, when the
768-byte prefix for each BLOB column was the cause of the limit
Error Code 1118: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. You have to change some columns to TEXT or BLOBs
A workaround for the problem was to create the table with the
ROW_FORMAT=COMPRESSED clause, which is now
suggested in the message.
(Bug #13453036, Bug #63507)
INFORMATION_SCHEMA tables originally
introduced in MySQL 5.6 are now also available in MySQL 5.5 and
SELECT ... FOR UPDATE,
UPDATE, or other SQL statement scanned rows
InnoDB table using a
<= operator in
WHERE clause, the next row after the
affected range could also be locked. This issue could cause a
lock wait timeout for a row that was not expected to be locked.
The issue occurred under various isolation levels, such as
READ COMMITTED and
Partitioning: The buffer for the row currently read from each partition used for sorted reads was allocated on open and freed only when the partitioning handler was closed or destroyed. For SELECT statements on tables with many partitions and large rows, this could cause the server to use excessive amounts of memory.
This issue has been addressed by allocating buffers for reads from partitioned tables only when they are needed and freeing them immediately once they are no longer needed. As part of this fix, memory is now allocated for reading from rows only in partitions that have not been pruned (see Partition Pruning). (Bug #13025132)
References: See also Bug #11764622, Bug #14537277.
In master-master replication with
setting a user variable and then performing inserts using this
variable caused the
column in the output of
STATUS not to be updated.
When resolving outer fields,
Item_field::fix_outer_fields() creates new
Item_refs for each execution of a prepared
statement, so these must be allocated in the runtime memroot.
The memroot switching before resolving
JOIN::having caused these to be allocated in
the statement root, leaking memory for each prepared statement
could result in a server crash.
libmysqlclient_r client library exported
yaSSL that conflict with
OpenSSL. If a program linked against that library and
libcurl, it could crash with a segmentation
(Bug #14068244, Bug #65055, Bug #14072299)
The argument for
LIMIT must be an integer,
but if the argument was given by a placeholder in a prepared
statement, the server did not reject noninteger values such as
INFORMATION_SCHEMA tables through a
view could leak memory.
A query for a
FEDERATED table could
return incorrect results when the underlying table had a
compound index on two columns and the query included an
AND condition on the columns.
In debug builds, an
assertion was overly aggressive about prohibiting an open range.
(Bug #66513, Bug #14547952)
The argument to the
option was not verified to exist and be a valid key. The
resulting connection used SSL, but the key was not used.
(Bug #62743, Bug #13115401)
LIMIT clause to a query containing
GROUP BY and
could cause the optimizer to choose an incorrect index for
processing the query, and return more rows than required.
(Bug #54599, Bug #11762052)
mysqlbinlog did not accept input on the standard input when the standard input was a pipe. (Bug #49336, Bug #11757312)