Functionality added or changed:
There is a new
variable to configure the locking behavior that
InnoDB uses for generating auto-increment
values. The default behavior now is slightly different from
before, which involves a minor incompatibility for multiple-row
inserts that specify an explicit value for the auto-increment
column in some but not all rows. See
Section 188.8.131.52, “
AUTO_INCREMENT Handling in
TIMESTAMP columns made
with ndb_restore on a MySQL Cluster using
data nodes hosts of one endian could not be used to restore the
cluster's data to data node hosts of the other endian.
Replication: Row-based replication from a pre-5.1.22 MySQL Server to a MySQL 5.1.22 was unstable due to an uninitialized variable. (Bug#31076)
Replication: Operations that used the time zone replicated the time zone only for successful operations, but did not replicate the time zone for errors that need to know it. (Bug#29536)
Memory corruption occurred for some queries with a top-level
OR operation in the
condition if they contained equality predicates and other
sargable predicates in disjunctive parts of the condition.
Under some circumstances, a UDF initialization function could be passed incorrect argument lengths. (Bug#29804)
This regression was introduced by Bug#21587.
Tables using the
InnoDB storage engine
AUTO_INCREMENT values incorrectly
ON DUPLICATE KEY UPDATE.
Nonrange queries of the form
SELECT ... FROM ... WHERE
sometimes were unnecessarily
blocked waiting for a lock if another transaction was using
ORDER BY ... FOR UPDATE
SELECT ... FOR
UPDATE on the same table.
On Windows, symbols for yaSSL and taocrypt were missing from
mysqlclient.lib, resulting in unresolved
symbol errors for clients linked against that library.
Read lock requests that were blocked by a pending write lock request were not allowed to proceed if the statement requesting the write lock was killed. (Bug#21281)