# Bugs fixed:

* Replication: When using unique keys on NULL columns in row-based replication, the slave sometimes chose the wrong row when performing an update. This happened because a table having a unique key on such a column could have multiple rows containing NULL for the column used by the unique key, and the slave merely picked the first row containing NULL in that column. (Bug#53893)
* Replication: FLUSH LOGS could in some circumstances crash the server. This occurred because the I/O thread could concurrently access the relay log I/O cache while another thread was performing the FLUSH LOGS, which closes and reopens the relay log and, while doing so, initializes (or re-initializes) its I/O cache. This could cause problems if some other thread (in this case, the I/O thread) is accessing it at the same time. Now the thread performing the FLUSH LOGS takes a lock on the relay log before actually flushing it. (Bug#50364)
* An ALTER TABLE statement could convert an InnoDB compressed table (with row_format=compressed) back to an uncompressed table (with row_format=compact). (Bug#54679)
* A signal-handler redefinition for SIGUSR1 was removed. The redefinition could cause the server to encounter a kernel deadlock on Solaris when there are many active threads. Other POSIX platforms might also be affected. (Bug#54667)
* InnoDB could issue an incorrect message on startup, if tables were created under the setting innodb_file_per_table=ON and the server was restarted under the setting innodb_file_per_table=OFF. The message was of the form InnoDB: Warning: allocated tablespace n, old maximum was 0. (Bug#54658)
* The make_binary_distribution target to make could fail on some platforms because the lines generated were too long for the shell. (Bug#54590)
* The server failed to disregard sort order for some zero-length tuples, leading to an assertion failure. (Bug#54459)
* The default value of myisam_max_extra_sort_file_size could be higher than the maximum accepted value, leading to warnings upon the server start. (Bug#54457)
* If a session tried to drop a database containing a table opened with HANDLER in another session, any DATABASE statement (CREATE, DROP, ALTER) executed by that session produced a deadlock. (Bug#54360)
* Fast index creation could fail, leaving the new secondary index corrupted. (Bug#54330)
* A client could supply data in chunks to a prepared statement parameter other than of type TEXT or BLOB using the mysql_stmt_send_long_data() C API function (or COM_STMT_SEND_LONG_DATA command). This led to a crash because other data types are not valid for long data. (Bug#54041)
* Builds of the embedded mysqld would fail due to a missing element of the struct NET. (Bug#53908, Bug#53912)
* The definition of the MY_INIT macro in my_sys.h included an extraneous semicolon, which could cause compilation failure. (Bug#53906)
* A client with automatic reconnection enabled saw the error message Lost connection to MySQL server during query if the connection was lost between the mysql_stmt_prepare() and mysql_stmt_execute() C API functions. However, mysql_stmt_errno() returned 0, not the corresponding error number 2013. (Bug#53899)
* Queries that used MIN() or MAX() on indexed columns could be optimized incorrectly. (Bug#53859)
* The Lock_time value in the slow query log was negative for stored routines. (Bug#53191)
* The results of some ORDER BY ... DESC queries were sorted incorrectly. (Bug#51431)
* Index Merge between three indexes could return incorrect results. (Bug#50389)
* Performing large numbers of RENAME TABLE statements caused excessive memory use. (Bug#47991)
* The server could crash with an out of memory error when trying to parse a query that was too long to fit in memory. Now the parser rejects such queries with an ER_OUT_OF_RESOURCES error. (Bug#42064)
* Sort-index_merge for join tables other than the first table used excessive memory. (Bug#41660)
* Valgrind warnings in the InnoDB compare_record() function were corrected. (Bug#38999)
* mysqld could fail during execution when using SSL. (Bug#34236)
* The behavior of the RPM upgrade installation has changed. During an upgrade installation using the RPM packages, if the MySQL server is running when the upgrade occurs, the server is stopped, the upgrade occurs, and server is restarted. If the server is not already running when the RPM upgrade occurs, the server is not started at the end of the upgrade. The boot scripts for MySQL are installed in the appropriate directories in /etc, so the MySQL server will be restarted automatically at the next machine reboot. (Bug#27072)