Changes 5.6.32:
Bugs Fixed

InnoDB: Full-text search auxiliary tables could be dropped by one session while being access by another.

InnoDB: Selecting full-text index information schema tables for a deleted table caused a segmentation fault.

InnoDB: Rollback of a full-text index synchronization operation raised an assertion. The rollback operation attempted to acquire a mutex still held by the background synchronization thread.

InnoDB: Setting innodb_monitor_enable to all did not enable all counters.

Replication: After issuing a PURGE BINARY LOGS statement, if the binary log index file was not available, for example because it had been opened by another application such as MEB, the server could stop unexpectedly. Although this situation was rare, the handling has been made more robust to avoid unexpected halts and more informative errors are provided.

Replication: When using row-based replication and InnoDB, replication slaves reverted to using an older locking scheme when a transaction had already acquired an AUTOINC lock related to a LOAD FILE or INSERT ... SELECT type of statement, reducing replication slave performance. The fix ensures that sql_command is set correctly for any of the DML events such as WRITE_ROWS_EVENT, UPDATE_EVENT, and DELETE_EVENT.

Replication: A MySQL version 5.5 slave does not have a server_uuid and replication identified servers by their server_id. Starting from MySQL version 5.6, replication masters detected a zombie dump thread based only on a slave's server_uuid value, under the assumption that each slave has a unique UUID. Connecting a MySQL 5.5 slave to a MySQL 5.6 and later master meant that the master was unable to detect zombie dump threads that were created to serve slaves running versions older than MySQL 5.6. The fix ensures that a master now first checks if a slave has a server_uuid set. If it is set, zombie dump thread detection happens based on the slave's UUID. If a slave's server_uuid is not set, zombie dump thread detection happens based on server_id.

Replication: With slave_skip_errors enabled there were still special cases when slave errors were not being correctly ignored. For example:

When opening and locking a table failed.

When field conversions failed on a server running row-based replication.

In these cases the error was considered critical and it was not respecting the state of slave_skip_errors. The fix ensures that with slave_skip_errors enabled, all errors reported during applying a transaction are correctly handled. This means that in such a set up, upon receiving an error with the log_warnings option set to greater than 1, if the error can be ignored then the warning is printed into the error log and the server continues as it does in the case of other ignored errors.

Replication: When using statement-based or mixed binary logging format with --read-only=ON, it was not possible to modify temporary tables.

MySQL Server upgrades performed using RPM packages failed when upgrading from MySQL 5.5 Community to MySQL 5.6 Community or MySQL 5.5 Commercial to MySQL 5.6 Commercial.

The code for reading character set information from Performance Schema statement events tables (for example, events_statements_current) did not prevent simultaneous writing to that information. As a result, the SQL query text character set could be invalid, which could result in a server exit. Now an invalid character set causes SQL_TEXT column truncation.

A buffer overflow in the regex library was fixed.

Certain arguments to NAME_CONST() could cause a server exit.

For unit-testing with the MySQL test suite, the make unit-test command is no longer available. The ctest program should be used instead. See Unit Tests Added to Main Test Runs.

ST_Distance() could raise an assertion for NULL return values.

With the query cache enabled, executing a prepared statement with CURSOR_TYPE_READ_ONLY and then again with CURSOR_TYPE_NO_CURSOR caused the server to return an error.

mysql_real_connect() was not thread-safe when invoked with the MYSQL_READ_DEFAULT_FILE or MYSQL_READ_DEFAULT_GROUP option enabled.

Installing MySQL from a yum or zypper repository resulted in /var/log/mysqld.log being created with incorrect user and group permissions.

If a stored function updated a view for which the view table had a trigger defined that updated another table, it could fail and report an error that an existing table did not exist.

If an INSTALL PLUGIN statement contained invalid UTF-8 characters in the shared library name, it caused the server to hang (or to raise an assertion in debug builds).

For multibyte character sets, LOAD DATA could fail to allocate space correctly and ignore input rows as a result.

(adam)