The mysqladmin and mysqldump clients now have --default-auth and --plugin-dir options for specifying which authentication plugin and plugin directory to use. (Bug#58139)

sql_priv.h now includes an OPTION_ALLOW_BATCH flag for the transaction_allow_batching feature of MySQL Cluster. (Bug#57604)

Partitioning: InnoDB Storage Engine: The partitioning handler did not pass locking information to a table's storage engine handler. This caused high contention and thus slower performance when working with partitioned InnoDB tables. (Bug#59013)

Partitioning: A failed ALTER TABLE ... TRUNCATE PARTITION statement was still written to the binary log. (Bug#58147)

Replication: While an INSERT DELAYED statement with a single inserted value does not return any visible warnings, such a warning could be still written into the error log. (Bug#57666)

See also Bug#49567.

Replication: When closing a session that used temporary tables, binary logging could sometimes fail with a spurious Failed to write the DROP statement for temporary tables to binary log. (Bug#57288)

Replication: Due to changes made in MySQL 5.5.3, settings made in the binlog_cache_size and max_binlog_cache_size server system variables affected both the binary log statement cache (also introduced in that version) and the binary log transactional cache (formerly known simply as the binary log cache). This meant that the resources used as a result of setting either or both of these variables were double the amount expected. To rectify this problem, these variables now affect only the transactional cache. The fix for this issue also introduces two new system variables binlog_stmt_cache_size and max_binlog_stmt_cache_size, which affect only the binary log statement cache.

In addition, the Binlog_cache_use status variable was incremented whenever either cache was used, and Binlog_cache_disk_use was incremented whenever the disk space from either cache was used, which caused problems with performance tuning of the statement and transactional caches, because it was not possible to determine which of these was being exceeeded when attempting to troubleshoot excessive disk seeks and related problems. This issue is solved by changing the behavior of these two status variables such that they are incremented only in response to usage of the binary log transactional cache, as well as by introducing two new status variables Binlog_stmt_cache_use and Binlog_stmt_cache_disk_use, which are incremented only by usage of the binary log statement cache.

For more information, see System variables used with the binary log, and Section 5.1.6, “Server Status Variables”. (Bug#57275)

Replication: By default, a value is generated for an AUTO_INCREMENT column by inserting either NULL or 0 into the column. Setting the NO_AUTO_VALUE_ON_ZERO server SQL mode suppresses this behavior for 0, so that it occurs only when NULL is inserted into the column.

This behavior is also followed on a replication slave (by the slave SQL thread) when applying events that have been logged on the master using the statement-based format. However, when applying events that had been logged using the row-based format, NO_AUTO_VALUE_ON_ZERO was ignored, which could lead to an assertion.

To fix this issue, the value of an AUTO_INCREMENT column is no longer generated when applying an event that was logged using the row-based row format, as this value is already contained in the changes applied on the slave. (Bug#56662)

Replication: The Binlog_cache_use and Binlog_cache_disk_use status variables were incremented twice by a change to a table using a transactional storage engine. (Bug#56343)

Replication: The BINLOG statement modified the values of session variables, which could lead to problems with operations such a point-in-time recovery. One such case occurred when replaying a row-based binary log which relied on setting foreign_key_checks = OFF on the session level in order to create and populate a set of InnoDB tables having foreign key constraints. (Bug#54903)

Replication: Previously, when a statement failed with a different error on the slave than on the master, the slave SQL thread displayed a message containing:

However, the slave has no information with which to fill in any print format specifiers for the master message, so it actually displayed the message format string. To make it clearer that the slave is not displaying the actual message as it appears on the master, the slave now indicates that the master part of the output is the message format, not the actual message. For example, previously the slave displayed information like this:

Error: "Query caused different errors on master and slave. Error on master: 'Duplicate entry '%-.192s' for key %d' (1062), Error on slave: 'no error' (0). Default database: 'test'. Query: 'insert into t1 values(1),(2)'" (expected different error codes on master and slave)

Now the slave displays this:

Error: "Query caused different errors on master and slave. Error on master: message format='Duplicate entry '%-.192s' for key %d' error code=1062 ; Error on slave: actual message='no error', error code=0. Default database: 'test'. Query: 'insert into t1 values(1),(2)'" (expected different error codes on master and slave) (Bug#46697)

Replication: When an error occurred in the generation of the name for a new binary log file, the error was logged but not shown to the user. (Bug#46166)

See also Bug#37148, Bug#40611, Bug#43929, Bug#51019.

Configuring MySQL with -DWITHOUT_PERFSCHEMA_STORAGE_ENGINE=1 caused build failures. (Bug#58953)

Several Valgrind warnings were fixed. (Bug#58948, Bug#59021)

On Solaris, the MySQL build failed if it was configured with debugging enabled. (Bug#58699)

If MySQL was built with Visual Studio Express, the project wixca was not built. (Bug#58411)

CMake polluted the source tree by writing installation-related temporary files there. (Bug#58372)

Security context references in sp_head.cc were rewritten for improved DTrace compatibility. (Bug#58350)

The ucs2 character set does not support characters outside the Basic Multilingual Plane (BMP), but converting a string containing such characters did not produce a conversion-failure warning. (Bug#58321)

CMake did not add LINK_LIBRARIES for MYSQL_ADD_PLUGIN for libmysqld. (Bug#58158)

Configuration with maintainer mode enabled resulted in errors when compiling with icc. (Bug#57991, Bug#58871)

The BIT_AND() function could return incorrect results when a join returned no matching rows. (Bug#57954)

View creation could produce Valgrind warnings. (Bug#57352)

The cp1251 character set did not properly support the Euro sign (0x88). For example, converting a string containing this character to utf8 resulted in '?' rather than the utf8 Euro sign. (Bug#56639)

Some unsigned system variables could be displayed with negative values. (Bug#55794)

CREATE DATABASE and DROP DATABASE caused mysql --one-database to lose track of the statement-filtering context. (Bug#54899)

An assertion could be raised during concurrent execution of DROP DATABASE and REPAIR TABLE if the drop deleted a table's .TMD file at the same time the repair tried to read details from the old file that was just removed.

A problem could also occur when DROP TABLE tried to remove all files belonging to a table at the same time REPAIR TABLE had just deleted the table's .TMD file. (Bug#54486)

During assignment of values to system variables, legality checks on the value range occurred too late, preventing proper error checking. (Bug#43233)