Changes in MySQL 5.6.25 (2015-05-29, General Availability)

Previously, enabling the
mysql_firewall_trace system
variable caused MySQL Enterprise Firewall to write a file named
firewall_trace.txt in the data directory.
That is no longer done. Now with
mysql_firewall_trace enabled,
for PROTECTING mode, the firewall writes
rejected statements to the error log.

Security Notes

my_print_defaults now masks passwords. To
display passwords in cleartext, use the new
--show option.
(Bug #19953365, Bug #20903330)

Functionality Added or Changed

MySQL Enterprise Firewall operates on parser states and does not work well together
with the query cache, which circumvents the parser. MySQL Enterprise Firewall now
checks whether the query cache is enabled. If so, it displays a
message that the query cache must be disabled and does not load.
(Bug #20913616)

MySQL distributions now include an
innodb_stress suite of test cases. Thanks to
Mark Callaghan for the contribution.
(Bug #76347, Bug #20717127)

Bugs Fixed

InnoDB; Partitioning:
The CREATE_TIME column of the
INFORMATION_SCHEMA.TABLES table now
shows the correct table creation time for partitioned
InnoDB tables. The
CREATE_TIME column of the
INFORMATION_SCHEMA.PARTITIONS table
now shows the correct partition creation time for a partition of
partitioned InnoDB tables.

The UPDATE_TIME column of the
INFORMATION_SCHEMA.TABLES table now shows
when a partitioned InnoDB table was last
updated by an INSERT,
DELETE, or
UPDATE. The
UPDATE_TIME column of the
INFORMATION_SCHEMA.PARTITIONS table now shows
when a partition of a partitioned InnoDB
table was last updated.
(Bug #69990, Bug #17299181)

InnoDB:
The innodb_checksum_algorithmstrict_* settings
(strict_none,
strict_innodb, and
strict_crc32) caused the server to halt when
InnoDB encountered a valid but non-matching
checksum. For example, with
innodb_checksum_algorithm=strict_crc32, a
valid innodb checksum would cause the server
to halt. Now, instead of halting the server,
InnoDB only prints an error message.
(Bug #20568464)

InnoDB:
The memcachedset command
permitted a negative expire time value. Expire time is stored
internally as an unsigned integer. A negative value would be
converted to a large number and accepted. The maximum expire
time value is now restricted to INT_MAX32 to
prevent negative expire time values.
(Bug #20478242, Bug #75790)

InnoDB:
Removal of a foreign key object from the data dictionary cache
during error handling caused the server to exit.
(Bug #20442523)

InnoDB:
Failure to check the status of a cursor transaction read-only
option before reusing the cursor transaction for a write
operation resulted in a server exit during a
memcached workload.
(Bug #20391552)

InnoDB:
Estimates that were too low for the size of merge chunks in the
result sorting algorithm caused a server exit.
(Bug #20049521)

InnoDB:
For full-text searches, the optimizer could choose an index that
does not produce correct relevancy rankings.
(Bug #74686, Bug #19950568)

Partitioning:
When creating a partitioned table, partition-level DATA
DIRECTORY or INDEX DIRECTORY option
values that contained an excessive number of characters were
handled incorrectly.
(Bug #20809045)

Partitioning:
Executing an ALTER TABLE on a
partitioned table on which a write lock was in effect could
cause subsequent SQL statements on this table to fail.
(Bug #74288, Bug #74634, Bug #19784790, Bug #19918805)

References: See also: Bug #19856162, Bug #74451.

Replication:
Row unpacking did not function correctly in some cases when
running the server with
binlog_row_image set to
minimal.
(Bug #20468712)

Replication:
When binary logging was enabled, using stored functions and
triggers resulting in a long running procedure that inserted
many records caused the memory use to increase rapidly. This was
due to memory being allocated per variable. The fix ensures that
in such a situation, memory is allocated once and the same
memory is reused.
(Bug #75879, Bug #20531812)

Replication:
If an error was encountered while adding a GTID to the received
GTID set, the log lock was not being correctly released. This
could cause a deadlock.
(Bug #75781, Bug #20492319)

Replication:
A slave running MySQL 5.6.24 or earlier could not connect to a
master running MySQL 5.7.6 and later that had
gtid_mode=OFF_PERMISSIVE or
gtid_mode=ON_PERMISSIVE. The
fix ensures that a slave running MySQL 5.6.25 and later can
connect to such a master as long as the slave's
gtid_mode is compatible. In
other words, a slave running MySQL 5.6.25 and later which has
gtid_mode=OFF can connect to a
master running MySQL 5.7.6 and later which has
gtid_mode=OFF_PERMISSIVE, and a
slave running MySQL 5.6.25 and later which has
gtid_mode=ON can connect to a
master running MySQL 5.7.6 and later which has
gtid_mode=ON_PERMISSIVE. Other
combinations are incompatible.
(Bug #75769, Bug #20471216)

Replication:
If an error occurred when using a multi-threaded slave, issuing
a CHANGE MASTER TO statement
which resulted in an
ER_MTS_CHANGE_MASTER_CANT_RUN_WITH_GAPS
error, and then issuing RESET
SLAVE, made it impossible to change master due to
repeated
ER_MTS_CHANGE_MASTER_CANT_RUN_WITH_GAPS
errors. Running the debug version of mysqld
caused an unexpected exit in this case. The fix ensures that the
recovery process for multi-threaded slaves avoids this.
(Bug #75574, Bug #20411374)

Replication:
When using semisynchronous replication performance was degrading
when the number of threads increased beyond a certain threshold.
To improve performance, now only the thread which is committing
is responsible for deleting the active transaction node. All
other operations do not touch this active transaction list.
(Bug #75570, Bug #20574628)

Replication:
Using mysqlbinlog to process log events
greater than 1.6GB failed with an out of memory error. This was
caused by an internal error converting the length variable. The
fix upgrades the length variable to avoid overflow in both
encoding and decoding functions.
(Bug #74734, Bug #20350989)

Replication:
When
master_info_repository=TABLE
the receiver thread stores received event information in a
table. The memory used in the process of updating the table was
not being freed correctly and this could lead to an out of
memory error. The fix ensures that after an event is flushed to
the relay log file by a receiver thread, the memory used is
freed.
(Bug #72885, Bug #19390463, Bug #69848, Bug #20124342)

Replication:
Using mysqlbinlog to replay a relay log which
ended with GTID_LOG_EVENT could cause the
following error:

ERROR 1790 (HY000) @@SESSION.GTID_NEXT cannot be
changed by a client that owns a GTID. The client owns
UUID:GTID. Ownership is released on
COMMIT or ROLLBACK.

If a relay log rotate happens (either through a receiver thread
restart or after issuing the ROTATE command)
exactly after writing a GTID_LOG_EVENT, when
replaying such a relay log's end
ROTATE_EVENT, it was mistakenly identified as
being inside a transaction, whereas the transaction was actually
started after GTID_LOG_EVENT. This caused
mysqlbinlog to append SET
@@SESSION.GTID_NEXT='AUTOMATIC', resulting in two
GTID_NEXT statements one after
the other. The fix ensures that mysqlbinlog
generates SET @@SESSION.GTID_NEXT='AUTOMATIC'
only outside of a transaction and when there has not been a
previous GTID_LOG_EVENT.

Similarly, using mysqlbinlog to concatenate
and replay a relay log which contained a partial GTID
transaction caused the above error. A relay log can contain a
partial GTID transaction when AUTO_POSITION
is enabled if a receiver thread is restarted when it is in the
middle of transferring a transaction from a master. On restart
the slave retrieves the full transaction again. In this case,
the first relay log contains a partial GTID transaction and the
second relay log contains the full GTID transaction again. When
using mysqlbinlog to concatenate such a relay
log, the partial transaction was not being correctly detected
and therefore a ROLLBACK was not being
correctly generated. The fix identifies partial GTID
transactions using the format description event of the second
relay log, ensuring that a ROLLBACK is
correctly added.
(Bug #70711, Bug #17650326)

For small values of the
read_rnd_buffer_size system
variable, internal caching of temporary results could fail and
cause query execution failure.
(Bug #20895852)

The normalize_statement() UDF used by MySQL Enterprise Firewall
could cause a server exit for certain password-related
statements.
(Bug #20873209)

A failed FLUSH PRIVILEGES
statement followed by statements to create or drop accounts
could cause a server exit.
(Bug #20857652)

For join queries with a large number of tables, the server could
exit converting the join to a semi-join.
(Bug #20109861)

Deleting rows from mysql.user following by
granting privileges to a new account could result in a server
exit.
(Bug #20031475)

Renaming the mysql.procs_priv table and
executing SHOW GRANTS resulted in
a server exit.
(Bug #20006361)

Within a stored procedure, access to view columns after DDL or
FLUSH TABLES statements in the
procedure could cause a server exit.
(Bug #19897405)

Execution of certain BINLOG
statements while temporary tables were open by
HANDLER statements could cause a
server exit.
(Bug #19894987, Bug #20449914)

For a prepared statement with an ORDER BY
that refers by column number to a
GROUP_CONCAT() expression that
has an outer reference, repeated statement execution could cause
a server exit.
(Bug #19814337)

CMake configuration was adjusted to handle
new warnings reported by Clang 3.5, using the
-Wpointer-bool-conversion and
-Wundefined-bool-conversion compiler options.
(Bug #19584183)

Loading corrupt spatial data into a MyISAM
table could cause the server to exit during index building.
(Bug #19573096)

In the threads Performance Schema
table, the PROCESSLIST_STATE and
PROCESSLIST_INFO values did not change for
the thread/sql/main main thread instrument as
the thread state changed.
(Bug #74517, Bug #19887143)

Certain queries for the INFORMATION_SCHEMATABLES and
COLUMNS tables could lead to
excessive memory use when there were large numbers of empty
InnoDB tables.
(Bug #72322, Bug #18592390)

Queries that included a HAVING clause based
on nondeterministic functions could produce incorrect results.
(Bug #69638, Bug #17055185)

For logging of prepared statements to the general query log, the
Execute line was logged after statement
execution, not before.
(Bug #69453, Bug #16953758, Bug #20536590)