MySQL 5.6.36

# Functionality Added or Changed
* The MySQL-shared-compat RPM package enables users of Red Hat-privided mysql-*-5.1 RPM packages to migrate to Oracle-provided MySQL-*-5.5 packages. MySQL-shared-compat now replaces the Red Hat mysql-libs package by replacing libmysqlclient.so files of the latter package, thus satisfying dependencies of other packages on mysql-libs. This change affects only users of Red Hat (or Red Hat-compatible) RPM packages. Nothing is different for users of Oracle RPM packages.
# Bugs Fixed
* Security Fix: Bug #59533 was fixed.
* Performance: Partitioning: InnoDB Storage Engine: The statistics used by the optimizer for queries against partitioned InnoDB tables were based only on the first partition of each such table, leading to use of the wrong execution plan.
* Performance: InnoDB Storage Engine: Improved the performance of the DROP TABLE statement for InnoDB tables, especially on systems with a large buffer pool. The fix speeds up the processing for freeing entries in the adaptive hash index.
* InnoDB Storage Engine: Deleting a huge amount of data from InnoDB tables within a short time could cause the purge operation that flushes data from the buffer pool to stall. If this issue occurs, restart the server to work around it. This issue is only likely to occur on 32-bit platforms.
* InnoDB Storage Engine: If the server crashed during a TRUNCATE TABLE or CREATE INDEX statement for an InnoDB table, or a DROP DATABASE statement for a database containing InnoDB tables, an index could be corrupted, causing an error message when accessing the table after restart:
- InnoDB: Error: trying to load index index_name for table table_name
- InnoDB: but the index tree has been freed!
In MySQL 5.1, this fix applies to the InnoDB Plugin, but not the built-in InnoDB storage engine.
* InnoDB Storage Engine: When data was removed from an InnoDB table, newly inserted data might not reuse the freed disk blocks, leading to an unexpected size increase for the system tablespace or .ibd file (depending on the setting of innodb_file_per_table. The OPTIMIZE TABLE could compact a .ibd file in some cases but not others. The freed disk blocks would eventually be reused as additional data was inserted.
* Partitioning: After updating a row of a partitioned table and selecting that row within the same transaction with the query cache enabled, then performing a ROLLBACK, the same result was returned by an identical SELECT issued in a new transaction.
* Replication: Formerly, the default value shown for the Port column in the output of SHOW SLAVE HOSTS was 3306 whether the port had been set incorrectly or not set at all. Now, when the slave port is not set, 0 is used as the default. This change also affects the default used for the --report-port server option.
* Replication: The --relay-log-space-limit option was sometimes ignored. More specifically, when the SQL thread went to sleep, it allowed the I/O thread to queue additional events in such a way that the relay log space limit was bypassed, and the number of events in the queue could grow well past the point where the relay logs needed to be rotated. Now in such cases, the SQL thread checks to see whether the I/O thread should rotate and provide the SQL thread a chance to purge the logs (thus freeing space). Note that, when the SQL thread is in the middle of a transaction, it cannot purge the logs; it can only ask for more events until the transaction is complete. Once the transaction is finished, the SQL thread can immediately instruct the I/O thread to rotate.
* An infinite thread loop could develop within Performance Schema, causing the server to become unresponsive.
* Incorrect stored program caching could cause statements within a stored program that included a GROUP BY clause to return different results across multiple program invocations.
* Mishandling of NO_BACKSLASH_ESCAPES SQL mode within stored procedures on slave servers could cause replication failures.
* SAVEPOINT statements were incorrectly disallowed within XA transactions.
* The Performance Schema incorrectly displayed some backslashes in Windows file names (by doubling them).
* SHOW statements treated stored procedure, stored function, and event names as case sensitive.

# Functionality Added or Changed
* InnoDB Storage Engine: A deprecation warning is now issued when --ignore-builtin-innodb is used.
* yaSSL was upgraded from version 1.7.2 to 2.2.0.
# Bugs Fixed
* Important Change: InnoDB Storage Engine: When a row grew in size due to an UPDATE operation, other (non-updated) columns could be moved to off-page storage so that information about the row still fit within the constraints of the InnoDB page size. The pointer to the new allocated off-page data was not set up until the pages were allocated and written, potentially leading to lost data if the system crashed while the column was being moved out of the page. The problem was more common with tables using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED along with the Barracuda file format, particularly with the innodb_file_per_table setting enabled, because page allocation operations are more common as the .ibd tablespace files are extended. Still, the problem could occur with any combination of InnoDB version, file format, and row format. A related issue was that during such an UPDATE operation, or an INSERT operation that reused a delete-marked record, other transactions could see invalid data for the affected column, regardless of isolation level. The fix corrects the order of operations for moving the column data off the original page and replacing it with a pointer. Now if a crash occurs at the precise moment when the column data is being transferred, the transfer will not be re-run during crash recovery. In MySQL 5.1, this fix applies to the InnoDB Plugin, but not the built-in InnoDB storage engine.
* InnoDB Storage Engine: An erroneous assertion could occur, in debug builds only, when creating an index on a column containing zero-length values (that is, '').
* InnoDB Storage Engine: A DDL operation such as ALTER TABLE ... ADD COLUMN could stall, eventually timing out with an Error 1005: Can't create table message referring to fil_rename_tablespace.
* InnoDB Storage Engine: A DDL operation for an InnoDB table could cause a busy MySQL server to halt with an assertion error: InnoDB: Failing assertion: trx->error_state == DB_SUCCESS The error occurred if the DDL operation was run while all 1023 undo slots were in use by concurrent transactions. This error was less likely to occur in MySQL 5.5 and 5.6, because raising the number of InnoDB undo slots increased the number of simultaneous transactions (corresponding to the number of undo slots) from 1K to 128K.
* InnoDB Storage Engine: Server startup could produce an error for temporary tables using the InnoDB storage engine, if the path in the $TMPDIR variable ended with a / character. The error log would look like:
120202 19:21:26 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
120202 19:21:26 InnoDB: Error: trying to open a table, but could not
InnoDB: open the tablespace file './t/#sql7750_1_0.ibd'!
InnoDB: Have you moved InnoDB .ibd files around without using the
InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE?
InnoDB: It is also possible that this is a temporary table #sql...,
InnoDB: and MySQL removed the .ibd file for this.
The workaround for the problem was to create a similar temporary table again, copy its .frm file to tmpdir under the name mentioned in the error message (for example, #sql123.frm) and restart mysqld with tmpdir set to its normal value without a trailing slash, for example /var/tmp. On startup, MySQL would see the .frm file and issue DROP TABLE for the orphaned temporary table.
* Replication: Statements that wrote to tables with AUTO_INCREMENT columns based on an unordered SELECT from another table could lead to the master and the slave going out of sync, as the order in which the rows are retrieved from the table may differ between them. Such statements include any INSERT ... SELECT, REPLACE ... SELECT, or CREATE TABLE ... SELECT statement. Such statements are now marked as unsafe for statement-based replication, which causes the execution of one to throw a warning, and forces the statement to be logged using the row-based format if the logging format is MIXED.
* The contents of the shared and shared-compat RPM packages had been changed in versions 5.5.6 and 5.6.1 to avoid the overlap which they traditionally had (and still have in MySQL 5.0 and 5.1). However, the RPM meta information had not been changed in accordance, and so RPM still assumed a conflict between shared and shared-compat RPM packages. This has been fixed.
* myisam_sort_buffer_size could not be set larger than 4GB on 64-bit systems.
* Due to improper locking, concurrent inserts into an ARCHIVE table at the same time as repair and check operations on the table resulted in table corruption.

# Functionality Added or Changed
* A new CMake option, MYSQL_PROJECT_NAME, can be set on Windows or Mac OS X to be used in the project name.
# Bugs Fixed
* Performance: InnoDB Storage Engine: Memory allocation for InnoDB tables was reorganized to reduce the memory overhead for large numbers of tables or partitions, avoiding situations where the “resident set size” could grow regardless of FLUSH TABLES statements. The problem was most evident for tables with large row size. Some of the memory that was formerly allocated for every open table is now allocated only when the table is modified for the first time.
* Incompatible Change: An earlier change (in MySQL 5.1.62 and 5.5.21) was found to modify date-handling behavior in General Availability-status series (MySQL 5.1 and 5.5). This change has been reverted. The change was that several functions became more strict when passed a DATE() function value as their argument, thus they rejected incomplete dates with a day part of zero. These functions were affected: CONVERT_TZ(), DATE_ADD(), DATE_SUB(), DAYOFYEAR(), LAST_DAY(), TIMESTAMPDIFF(), TO_DAYS(), TO_SECONDS(), WEEK(), WEEKDAY(), WEEKOFYEAR(), YEARWEEK(). The previous behavior has been restored.
* InnoDB Storage Engine: A Valgrind error was fixed in the function os_aio_init().
* InnoDB Storage Engine: The server could crash when creating an InnoDB temporary table under Linux, if the $TMPDIR setting points to a tmpfs filesystem and innodb_use_native_aio is enabled, as it is by default in MySQL 5.5.4 and higher. The entry in the error log looked like: 101123 2:10:59 InnoDB: Operating system error number 22 in a file operation. InnoDB: Error number 22 means 'Invalid argument'. The crash occurred because asynchronous I/O is not supported on tmpfs in some Linux kernel versions. The workaround was to turn off the innodb_use_native_aio setting or use a different temporary directory. The fix causes InnoDB to turn off the innodb_use_native_aio setting automatically if it detects that the temporary file directory does not support asynchronous I/O.
* InnoDB Storage Engine: References to C preprocessor symbols and macros HAVE_purify, UNIV_INIT_MEM_TO_ZERO, and UNIV_SET_MEM_TO_ZERO were removed from the InnoDB source code. They were only used in debug builds instrumented for Valgrind. They are replaced by calls to the UNIV_MEM_INVALID() macro.
* InnoDB Storage Engine: The MySQL server could halt with an assertion error: InnoDB: Failing assertion: page_get_n_recs(page) > 1 Subsequent restarts could fail with the same error. The error occurred during a purge operation involving the InnoDB change buffer. The workaround was to set the configuration option innodb_change_buffering=inserts.
* InnoDB Storage Engine: With 1024 concurrent InnoDB transactions running concurrently and the innodb_file_per_table setting enabled, a CREATE TABLE operation for an InnoDB table could fail. The .ibd file from the failed CREATE TABLE was left behind, preventing the table from being created later, after the load had dropped. The fix adds error handling to delete the erroneous .ibd file. This error was less likely to occur in MySQL 5.5 and 5.6, because raising the number of InnoDB undo slots increased the number of simultaneous transactions needed to trigger the bug, from 1K to 128K.
* Replication: Executing mysqlbinlog with the --start-position=N option, where N was equal either to 0 or to a value greater than the length of the dump file, caused it to crash. This issue was introduced in MySQL 5.5.18 by the fix for Bug #32228 and Bug #11747416.
* Replication: On Windows replication slave hosts, STOP SLAVE took an excessive length of time to complete when the master was down.
* A query that used an index on a CHAR column referenced in a BETWEEN clause could return invalid results.
* Expressions that compared a BIGINT column with any non-integer constant were performed using integers rather than decimal or float values, with the result that the constant could be truncated. This could lead to any such comparison that used <, >, <=, >=, =, !=/<>, IN, or BETWEEN yielding false positive or negative results.
* When the optimizer performed conversion of DECIMAL values while evaluating range conditions, it could produce incorrect results.
* When running mysqldump with both the --single-transaction and --flush-logs options, the flushing of the log performed an implicit COMMIT (see Section 12.3.3, “Statements That Cause an Implicit Commit”), causing more than one transaction to be used and thus breaking consistency.
* It was possible in the event of successive failures for mysqld_safe to restart quickly enough to consume excessive amounts of CPU. Now, on systems that support the sleep and date system utilities, mysqld_safe checks to see whether it has restarted more than 5 times in the current second, and if so, waits 1 second before attempting another restart.
* When used with the --xml option, mysqldump --routines failed to dump any stored routines, triggers, or events.
* It was possible on replication slaves where FEDERATED tables were in use to get timeouts on long-running operations, such as Error 1160 Got an error writing communication packets. The FEDERATED tables did not need to be replicated for the issue to occur.
* If an attempt to initiate a statement failed, the issue could not be reported to the client because it was not prepared to receive any error messages prior to the execution of any statement. Since the user could not execute any queries, they were simply disconnected without providing a clear error. After the fix for this issue, the client is prepared for an error as soon as it attempts to initiate a statement, so that the error can be reported prior to disconnecting the user.
* Using myisamchk with the sort recover method to repair a table having fixed-width row format could cause the row pointer size to be reduced, effectively resulting in a smaller maximum data file size.
* On Windows, the server incorrectly constructed the full path name of the plugin binary for INSTALL PLUGIN and CREATE FUNCTION ... SONAME.
* The stored routine cache was subject to a small memory leak that over time or with many routines being used could result in out-of-memory errors.

# Bugs Fixed
* Important Change: Replication: Setting an empty user in a CHANGE MASTER TO statement caused an invalid internal result and is no longer permitted. Trying to use MASTER_USER='' or setting MASTER_PASSWORD while leaving MASTER_USER unset causes the statement to fail with an error.
* Important Change: Replication: Moving the binary log file, relay log file, or both files to a new location, then restarting the server with a new value for --log-bin, --relay-log, or both, caused the server to abort on start. This was because the entries in the index file overrode the new location. In addition, paths were calculated relative to datadir (rather than to the --log-bin or --relay-log values). The fix for this problem means that, when the server reads an entry from the index file, it now checks whether the entry contains a relative path. If it does, the relative part of the path is replaced with the absolute path set using the --log-bin or --relay-log option. An absolute path remains unchanged; in such a case, the index must be edited manually to enable the new path or paths to be used.
* InnoDB Storage Engine: When doing a live downgrade from MySQL 5.6.4 or later, with innodb_page_size set to a value other than 16384, now the earlier MySQL version reports that the page size is incompatible with the older version, rather than crashing or displaying a “corruption” error.
* InnoDB Storage Engine: Issuing INSERT...ON DUPLICATE KEY statements for InnoDB tables from concurrent threads could cause a deadlock, particularly with the INSERT...ON DUPLICATE KEY UPDATE form. The fix avoids deadlocks caused by the same row being accessed by more than one transaction. Deadlocks could still occur when multiple rows are inserted and updated simultaneously by different transactions in inconsistent order; those types of deadlocks require the standard error handling on the application side, of re-trying the transaction.
* An incorrect InnoDB assertion could cause the server to halt. This issue only affected debug builds. The assertion referenced the source file btr0pcur.ic and the variable cursor->pos_state.
* Locale information for FORMAT() function instances was lost in view definitions.
* The handle_segfault() signal-handler code in mysqld could itself crash due to calling unsafe functions.
* Enabling myisam_use_mmap could cause the server to crash.
* Concurrent access to ARCHIVE tables could cause corruption.

# Bugs Fixed
* InnoDB Storage Engine: An incorrect deadlock could occur on a server doing a substantial amount of change buffering for DML operations, particularly DELETE statements.
* Rounding DBL_MAX returned DBL_MAX, not 'inf'.
* mysql_upgrade did not upgrade the system tables or create the mysql_upgrade_info file when run with the --write-binlog or --skip-write-binlog option.
* If a plugin was uninstalled, thread local variables for plugin variables of string type with wth PLUGIN_VAR_MEMALLOC flag were not freed.
* Deadlock could occur when these four things happened at the same time: 1) An old dump thread was waiting for the binary log to grow. 2) The slave server that replicates from the old dump thread tried to reconnect. During reconnection, the new dump thread tried to kill the old dump thread. 3) A KILL statement tried to kill the old dump thread. 4) An INSERT statement caused a binary log rotation.

# Bugs Fixed
* Incompatible Change: Replication: The statements in the following list are now marked as unsafe for statement-based replication. This is due to the fact that each of these statements depends on the results of a SELECT statement whose order cannot always be determined. When using STATEMENT logging mode, a warning is issued in the binary log for any of these statements; when using MIXED logging mode, the statement is logged using the row-based format.
- INSERT ... SELECT ... ON DUPLICATE KEY UPDATE
- REPLACE ... SELECT
- CREATE TABLE ... IGNORE SELECT
- CREATE TABLE ... REPLACE SELECT
- INSERT IGNORE ... SELECT
- UPDATE IGNORE
When upgrading, you should note the use of these statements in your applications, keeping in mind that a statement that inserts or replaces rows obtained from a SELECT can take up many times as much space in the binary log when logged using row-based format than when only the statement itself is logged. Depending on the number and size of the rows selected and inserted (or replaced) by any such statements, the difference in size of the binary log after the logging of these statements is switched from statement-based to row-based can potentially be several orders of magnitude. See Section 15.1.2.1, “Advantages and Disadvantages of Statement-Based and Row-Based Replication”.
* Replication: A replication master could send damaged events to slaves after the binary log disk on the master became full. To correct this issue, only complete events are now pushed by the master dump thread to the slave I/O thread. In addition, the error text that the master sends to the slave when an incomplete event is found now states that the incomplete event may have been caused by running out of disk space on the master, and provides coordinates of the first and the last event bytes read.
* mysql_plugin mishandled the --plugin-ini, --mysqld, and --my-print-defaults options under some circumstances.
* mysql_plugin returned the wrong error code from failed server bootstrap execution.
* Several improvements were made to the libedit library bundled with MySQL distributions, and that is available for all platforms that MySQL supports except Windows.
- Navigation keys did not work for UTF-8 input.
- Word navigation and delete operations did not work for UTF-8 input with Cyrillic characters.
- Nonlatin characters were corrupted in overwrite mode for UTF-8 input.
- Long queries caused the statement history file to become corrupted.
- The Alt key caused history operations to fail.
* ARCHIVE tables with NULL columns could cause server crashes or become corrupt under concurrent load.
* OPTIMIZE TABLE could corrupt MyISAM tables if myisam_use_mmap was enabled.
* A query that selected a GROUP_CONCAT() function result could return different values depending on whether an ORDER BY of the function result was present.
* For FEDERATED tables, loss of connection to the remote table during some insert operations could cause a server crash.

# Bugs Fixed :
* InnoDB Storage Engine: This fix improves the performance of instrumentation code for InnoDB buffer pool operations.
* InnoDB Storage Engine: Data from BLOB columns could be lost if the server crashed at a precise moment when other columns were being updated in an InnoDB table.
* InnoDB Storage Engine: Lookups using secondary indexes could give incorrect matches under a specific set of conditions. The conditions involve an index defined on a column prefix, for a BLOB or other long column stored outside the index page, with a table using the Barracuda file format.
* InnoDB Storage Engine: This fix corrects cases where the MySQL server could hang or abort with a long semaphore wait message. (This is a different issue than when these symptoms occurred during a CHECK TABLE statement.)
* Internal conversion of zero to binary and back could yield a result with incorrect precision.
* Valgrind warnings generated by filesort operations were fixed.
* mysqld_safe did not properly check for an already running instance of mysqld.
* The help message for mysql_install_db did not indicate that it supports the --defaults-file, --defaults-extra-file and --no-defaults options.
* An assertion designed to detect zero-length sort keys also was raised when the entire key set fit in memory.
* myisampack could create corrupt FULLTEXT indexes when compressing tables.
* A linking problem prevented the FEDERATED storage engine plugin from loading.

# Bugs Fixed
* InnoDB Storage Engine: The “random read-ahead” feature that was removed from the InnoDB Plugin is now available again. Because it is only helpful for certain workloads, it is turned off by default. To turn it on, enable the innodb_random_read_ahead configuration option. Because this feature can improve performance in some cases and reduce performance in others, before relying on this setting, benchmark both with and without the setting enabled.
* The metadata locking subsystem added too much overhead for INFORMATION_SCHEMA queries that were processed by opening only .frm or .TRG files and had to scan many tables. For example, SELECT COUNT(*) FROM INFORMATION_SCHEMA.TRIGGERS was affected.
* Compilation failed on Mac OS X 10.7 (Lion) with a warning: Implicit declaration of function 'pthread_init'
* With profiling disabled or not compiled in, set_thd_proc_info() unnecessarily checked file name lengths.
* A DBUG_ASSERT added by Bug #11792200 was overly aggressive in raising assertions.
* CHECK TABLE and REPAIR TABLE failed to find problems with MERGE tables that had underlying tables missing or with the wrong storage engine. Issues were reported only for the first underlying table.
* Replication: Processing of corrupted table map events could cause the server to crash. This was especially likely if the events mapped different tables to the same identifier, such as could happen due to Bug#56226. Now, before applying a table map event, the server checks whether the table has already been mapped with different settings, and if so, an error is raised and the slave SQL thread stops. If it has been mapped with the same settings, or if the table is set to be ignored by filtering rules, there is no change in behavior: the event is skipped and IDs are not checked.
* For a lower_case_table_names value of 1 or 2 and a database having a mixed-case name, calling a stored function using a fully qualified name including the database name failed.
* Previously, Performance Schema table columns that held byte counts were BIGINT UNSIGNED. These were changed to BIGINT (signed). This makes it easier to perform calculations that compute differences between columns.
* The embedded server crashed when argc = 0.
* The mysql_affected_rows() C API function returned 3 (instead of 2) for INSERT ... ON DUPLICATE KEY UPDATE statements where there was a duplicated key value.
* Upgrades using an RPM package recreated the test database, which is undesirable when the DBA had removed it.

# Bugs Fixed :
* InnoDB Storage Engine: A failed CREATE INDEX operation for an InnoDB table could result in some memory being allocated and not freed. This memory leak could affect tables created with the ROW_FORMAT=DYNAMIC and ROW_FORMAT=COMPRESSED settings.
* Partitioning: Auto-increment columns of partitioned tables were checked even when they were not being written to. In debug builds, this could lead to a crash of the server.
* Partitioning: The UNIX_TIMESTAMP() function was not treated as a monotonic function for purposes of partition pruning.
* Replication: If a LOAD DATA INFILE statement—replicated using statement-based replication—featured a SET clause, the name-value pairs were regenerated using a method (Item::print()) intended primarily for generating output for statements such as EXPLAIN EXTENDED, and which cannot be relied on to return valid SQL. This could in certain cases lead to a crash on the slave. To fix this problem, we now name each value in its original, user-supplied form, and use that to create LOAD DATA INFILE statements for statement-based replication.
* Previously, an inappropriate error message was produced if a multiple-table update for an InnoDB table with a clustered primary key would update a table through multiple aliases, and perform an update that may physically move the row in at least one of these aliases. Now the error message is: Primary key/partition key update is not allowed since the table is updated both as 'tbl_name1' and 'tbl_name2'
* ALTER TABLE {MODIFY|CHANGE} ... FIRST did nothing except rename columns if the old and new versions of the table had exactly the same structure with respect to column data types. As a result, the mapping of column name to column data was incorrect. The same thing happened for ALTER TABLE DROP COLUMN, ADD COLUMN statements intended to produce a new version of table with exactly the same structure as the old version.
* Incorrect handling of metadata locking for FLUSH TABLES WITH READ LOCK for statements requiring prelocking caused two problems:
- Execution of any data-changing statement that required prelocking (that is, involved a stored function or trigger) as part of transaction slowed down somewhat all subsequent statements in the transaction. Performance in a transaction that periodically involved such statements gradually degraded over time.
- Execution of any data-changing statement that required prelocking as part of transaction prevented a concurrent FLUSH TABLES WITH READ LOCK from proceeding until the end of transaction rather than at the end of the particular statement.
* The fractional part of the “Queries per second” value in MySQL status output could be displayed incorrectly.
* LOAD DATA INFILE incorrectly parsed relative data file path names that ascended more than three levels in the file system and as a consequence was unable to find the file.
* For MyISAM tables, attempts to insert incorrect data into an indexed GEOMETRY column could result in table corruption.
* In debug builds, Field_new_decimal::store_value() was subject to buffer overflows.
* A race condition between loading a stored routine using the name qualified by the database name and dropping that database resulted in a spurious error message: The table mysql.proc is missing, corrupt, or contains bad data

# Functionality added or changed:

* CMake configuration support on Linux now provides a boolean ENABLE_GCOV option to control whether to include support for gcov.
* Client programs now display more information for SSL errors to aid in diagnosis and debugging of connection problems.
* In the audit plugin interface, the event_class member was removed from the mysql_event_general structure and the calling sequence for the notification function changed. Originally, the second argument was a pointer to the event structure. The function now receives this information as two arguments: an event class number and a pointer to the event. Corresponding to these changes, MYSQL_AUDIT_INTERFACE_VERSION was increased to 0x0300.


# Bugs fixed:
* Replication: A mistake in thread cleanup could cause a replication master to crash.
* Replication: When using row-based replication and attribute promotion or demotion (see Section 15.4.1.6.2, “Replication of Columns Having Different Data Types”), memory allocated internally for conversion of BLOB columns was not freed afterwards.
* Adding support for Windows authentication to libmysql introduced a link dependency on the system Secur32 library. The Microsoft Visual C++ link information was modified to pull in this library automatically.
* In some cases, memory allocated for Query_tables_list::sroutines() was not freed properly.
* After the fix for Bug#11889186, MAKEDATE() arguments with a year part greater than 9999 raised an assertion.
* An assertion could be raised due to a missing NULL value check in Item_func_round::fix_length_and_dec().
* An assertion could be raised during two-phase commits if the binary log was used as the transaction coordinator log.
* A problem introduced in 5.5.11 caused very old (MySQL 4.0) clients to be unable to connect to the server.
* Using CREATE EVENT IF NOT EXISTS for an event that already existed and was enabled caused multiple instances of the event to run.
* An embedded client would abort rather than issue an error message if it issued a TEE command (T file_name) and the directory containing the file did not exist. This occurred because the wrong error handler was called.
* On some platforms, the Incorrect value: xxx for column yyy at row zzz error produced by LOAD DATA INFILE could have an incorrect value of zzz.
* An attempt to install nonexistent files during installation was corrected.
* On FreeBSD 64-built builds of the embedded server, exceptions were not prevented from propagating into the embedded application.

# Bugs fixed:

* InnoDB Storage Engine: If the server crashed while an XA transaction was prepared but not yet committed, the transaction could remain in the system after restart, and cause a subsequent shutdown to hang.
* InnoDB Storage Engine: Similar problem to the foreign key error in bug #11831040 / 60196 / 60909, but with a different root cause and occurring on Mac OS X. With the setting lower_case_table_names=2, inserts into InnoDB tables covered by foreign key constraints could fail after a server restart.
* Partitioning: The internal get_partition_set() function did not take into account the possibility that a key specification could be NULL in some cases.
* Partitioning: When executing a row-ordered retrieval index merge, the partitioning handler used memory from from that allocated for the table, rather than that allocated to the query, causing table object memory not to be freed until the table was closed.
* Replication: A spurious error malformed binlog: it does not contain any Format_description_log_event... was generated when mysqlbinlog was invoked using --base64-output=decode-row and --start-position=pos, where pos is a point in the binary log past the format description log event. However, there is nothing unsafe about not printing the format description log event, so the error has been removed for this case.
* Replication: Typographical errors appeared in the text of several replication error messages. (The word “position” was misspelled as “postion”.)
* Assignments to NEW.var_name within triggers, where var_name had a BLOB or TEXT type, were not properly handled and produced incorrect results.
* XA COMMIT could fail to clean up the error state if it discovered that the current XA transaction had to be rolled back. Consequently, the next XA transaction could raise an assertion when it checked for proper cleanup of the previous transaction.
* An internal client macro reference was removed from the client_plugin.h header file. This reference made the file unusable.
* The server consumed memory for repeated invocation of some stored procedures, which was not released until the connection terminated.
* The server did not check for certain invalid out of order sequences of XA statements, and these sequences raised an assertion.
* With the conversion from GNU autotools to CMake for configuring MySQL, the USE_SYMDIR preprocessor symbol was omitted. This caused failure of symbolic links (described at Section 7.11.3.1, “Using Symbolic Links”).
* The incorrect max_length value for YEAR values could be used in temporary result tables for UNION, leading to incorrect results.
* In Item_func_in::fix_length_and_dec(), a Valgrind warning for uninitialized values was corrected.
* In ROUND() calculations, a Valgrind warning for uninitialized memory was corrected.
* Valgrind warnings caused by comparing index values to an uninitialized field were corrected.
* LOAD DATA INFILE errors could leak I/O cache memory.
* For LOAD DATA INFILE, multibyte character sequences could be pushed onto a stack too small to accommodate them.
* Internal Performance Schema header files were unnecessarily installed publicly.
* On Linux, the mysql client built using the bundled libedit did not read ~/.editrc.
* The optimizer sometimes incorrectly processed HAVING clauses for queries that did not also have an ORDER BY clause.
* PROCEDURE ANALYZE() could leak memory for NULL results, and could return incorrect results if used with a LIMIT clause.
* With DISTINCT CONCAT(col,...) returned incorrect results when the arguments to CONCAT() were columns with an integer data type declared with a display width narrower than the values in the column. (For example, if an INT(1) column contain 1111.)

# Bugs fixed:

- InnoDB Storage Engine: Replication: Trying to update a column, previously set to NULL, of an InnoDB table with no primary key caused replication to fail with Can't find record in 'table' on the slave.
- InnoDB Storage Engine: The server could halt if InnoDB interpreted a very heavy I/O load for 15 minutes or more as an indication that the server was hung. This change fixes the logic that measures how long InnoDB threads were waiting, which formerly could produce false positives.
- InnoDB Storage Engine: With the setting lower_case_table_names=2, inserts into InnoDB tables covered by foreign key constraints could fail after a server restart.
- Replication: Using the --server-id option with mysqlbinlog could cause format description log events to be filtered out of the binary log, leaving mysqlbinlog unable to read the remainder of the log. Now such events are always read without regard to the value of this option.
- As part of the the fix for this problem, mysqlbinlog now also reads rotate log events without regard to the value of --server-id.
- On Windows, the server rejected client connections if no DNS server was available.
- mysql_upgrade did not properly upgrade the authentication_string column of the mysql.user table.
- InnoDB invoked some zlib functions without proper initialization.
- Comparison of a DATETIME stored program variable and NOW() led to an “Illegal mix of collations error” when character_set_connection was set to utf8. (Bug #60625, Bug #11926811)
- Selecting from a view for which the definition included a HAVING clause failed with an error:
* 1356: View '...' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
- CREATE TABLE syntax permits specification of a STORAGE {DEFAULT|DISK|MEMORY} option. However, this value was not written to the .frm file, so that a subsequent CREATE TABLE ... LIKE for the table did not include that option.
* Also, ALTER TABLE of a table that had a tablespace incorrectly destroyed the tablespace.
- The server permitted max_allowed_packet to be set lower than net_buffer_length, which does not make sense because max_allowed_packet is the upper limit on net_buffer_length values. Now a warning occurs and the value remains unchanged.
- A missing variable initialization for Item_func_set_user_var objects could cause an assertion to be raised.
- When the server was started with the --skip-innodb option, it initialized the have_innodb system variable to YES rather than DISABLED.
- In Item_func_month::val_str(), a Valgrind warning for a too-late NULL value check was corrected.
- In Item::get_date, a Valgrind warning for a missing NULL value check was corrected.
- In extract_date_time(), a Valgrind warning for a missing end-of-string check was corrected.
- In string context, the MIN() and MAX() functions did not take into account the unsignedness of a BIGINT UNSIGNED argument.
- In Item_func::val_decimal, a Valgrind warning for a missing NULL value check was corrected.
- In Item_func_str_to_date::val_str, a Valgrind warning for an uninitialized variable was corrected.
- An assertion could be raised in Item_func_int_val::fix_num_length_and_dec() due to overflow for geometry functions.
- With prepared statements, the server could attempt to send result set metadata after the table had been closed.
- With lower_case_table_names=2, resolution of objects qualified by database names could fail.
- SHOW EVENTS did not always show events from the correct database.

# Bugs fixed:

* Partitioning: A problem with a previous fix for poor performance of INSERT ON DUPLICATE KEY UPDATE statements on tables having many partitions caused the handler function for reading a row from a specific index to fail to store the ID of the partition last used. This caused some statements to fail with Can't find record errors.
* An assertion was raised if an XA COMMIT was issued when an XA transaction had already encountered an error (such as a deadlock) that required the transaction to be rolled back.
* On some systems, debug builds of comp_err.c could fail due to an uninitialized variable.
* The server read one byte too many when trying to process an XML string lacking a closing quote (') or double quote (") character used as an argument for UpdateXML() or ExtractValue().
* Attempting to create a spatial index on a CHAR column longer than 31 bytes led to an assertion failure if the server was compiled with safemutex support.
* Aggregation followed by a subquery could produce an incorrect result.
* An incorrect character set pointer passed to my_strtoll10_mb2() caused an assertion to be raised.
* mysqldump did not quote database names in ALTER DATABASE statements in its output, which could cause an error at reload time for database names containing a dash.
* The MYSQL_HOME environment variable was being ignored.
* If a multiple-table update updated a row through two aliases and the first update physically moved the row, the second update failed to locate the row. This resulted in different errors depending on storage engine, although these errors did not accurately describe the problem:
- MyISAM: Got error 134 from storage engine
- InnoDB: Can't find record in 'tbl'
For MyISAM, which is nontransactional, the update executed first was performed but the second was not. In addition, for two equal multiple-table update statements, one could succeed and the other fail depending on whether the record actually moved, which is inconsistent.
Now such an update returns an error if it will update a table through multiple aliases, and perform an update that may physically more the row in at least one of these aliases.
* SHOW WARNINGS output following EXPLAIN EXTENDED could include unprintable characters.
* When CASE ... WHEN arguments had different character sets, 8-bit values could be referenced as utf16 or utf32 values, causing an assertion to be raised.
* Bitmap functions used in one thread could change bitmaps used by other threads, causing an assertion to be raised.

# Bugs fixed:

* InnoDB Storage Engine: Raised the number of I/O requests that each AIO helper thread could process, from 32 to 256. The new limit applies to Linux and Unix platforms; the limit on Windows remains 32.
* InnoDB Storage Engine: InnoDB returned values for “rows examined” in the query plan that were higher than expected. NULL values were treated in an inconsistent way. The inaccurate statistics could trigger “false positives” in combination with the MAX_JOIN_SIZE setting, because the queries did not really examine as many rows as reported.
* Replication: When using the statement-based logging format, INSERT ON DUPLICATE KEY UPDATE and INSERT IGNORE statements affecting transactional tables that did not fail were not written to the binary log if they did not insert any rows. (With statement-based logging, all successful statements should be logged, whether they do or do not cause any rows to be changed.)
* Replication: Formerly, STOP SLAVE stopped the slave I/O thread first and then stopped the slave SQL thread; thus, it was possible for the I/O thread to stop after replicating only part of a transaction which the SQL thread was executing, in which case—if the transaction could not be rolled back safely—the SQL thread could hang.
Now, STOP SLAVE stops the slave SQL thread first and then stops the I/O thread; this guarantees that the I/O thread can fetch any remaining events in the transaction that the SQL thread is executing, so that the SQL thread can finish the transaction if it cannot be rolled back safely.
* DES_DECRYPT() could crash if the argument was not produced by DES_ENCRYPT().
* The server and client did not always properly negotiate authentication plugin names.
* --autocommit=ON did not work (it set the global autocommit value to 0, not 1).
* A query of the following form returned an incorrect result, where the values for col_name in the result set were entirely replaced with NULL values:
SELECT DISTINCT col_name ... ORDER BY col_name DESC;
* SHOW PRIVILEGES did not display a row for the PROXY privilege.
* SHOW PROFILE could truncate source file names or fail to show function names.
* DELETE or UPDATE statements could fail if they used DATE or DATETIME values with a year, month, or day part of zero.
* The ESCAPE clause for the LIKE operator allows only expressions that evaluate to a constant at execution time, but aggregate functions were not being rejected.
* Memory leaks detected by Valgrind, some of which could cause incorrect query results, were corrected.
* The DEFAULT_CHARSET and DEFAULT_COLLATION CMake options did not work.
* An OUTER JOIN query using WHERE column IS NULL could return an incorrect result.
* Starting the server with the --defaults-file=file_name option, where the file name had no extension, caused a server crash.
* Outer joins with an empty table could produce incorrect results.
* In debug builds, SUBSTRING_INDEX(FORMAT(...), FORMAT(...)) could cause a server crash.
* When mysqladmin was run with the --sleep and --count options, it went into an infinite loop executing the specified command.
* Some string manipulating SQL functions use a shared string object intended to contain an immutable empty string. This object was used by the SQL function SUBSTRING_INDEX() to return an empty string when one argument was of the wrong datatype. If the string object was then modified by the SQL function INSERT(), undefined behavior ensued.
* Parsing nested regular expressions could lead to recursion resulting in a stack overflow crash.
* The fix for Bug#25192 caused load_defaults() to add an argument separator to distinguish options loaded from configure files from those provided on the command line, whether or not the application needed it.
* The mysql client went into an infinite loop if the standard input was a directory.
* Outer joins on a unique key could return incorrect results.
* The expression const1 BETWEEN const2 AND field was optimized incorrectly and produced incorrect results.
* Some RPM installation scripts used a hardcoded value for the data directory, which could result in a failed installation for users who have a nonstandard data directory location. The same was true for other configuration values such as the PID file name.
* On FreeBSD and OpenBSD, the server incorrectly checked the range of the system date, causing legal values to be rejected.
* Sorting using ORDER BY AVG(DISTINCT decimal_col) caused a server crash or incorrect results.
* When using ExtractValue() or UpdateXML(), if the XML to be read contained an incomplete XML comment, MySQL read beyond the end of the XML string when processing, leading to a crash of the server.
* DATE_ADD() and DATE_SUB() return a string if the first argument is a string, but incorrectly returned a binary string. Now they return a character string with a collation of connection_collation.

# Bugs fixed:

* Incompatible Change: When auto_increment_increment is greater than one, values generated by a bulk insert that reaches the maximum column value could wrap around rather producing an overflow error.
As a consequence of the fix, it is no longer possible for an auto-generated value to be equal to the maximum BIGINT UNSIGNED value. It is still possible to store that value manually, if the column can accept it. (Bug#39828)
* Important Change: Partitioning: Date and time functions used as partitioning functions now have the types of their operands checked; use of a value of the wrong type is now disallowed in such cases. In addition, EXTRACT(WEEK FROM col), where col is a DATE or DATETIME column, is now disallowed altogether because its return value depends on the value of the default_week_format system variable. (Bug#54483)
See also Bug#57071.
* 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)
* InnoDB Storage Engine: When multiple InnoDB buffer pools were enabled, SHOW ENGINE INNODB commands displayed information about each one, but not summary information combining statistics for the entire buffer pool subsystem. Now, the aggregated information is displayed in the BUFFER POOL AND MEMORY section, and information about individual buffer pool instances is displayed in a new INDIVIDUAL BUFFER POOL INFO section. (Bug#58461)
* InnoDB Storage Engine: The command to create a debug build (cmake -DWITH_DEBUG ...) now automatically sets the InnoDB debugging flag UNIV_DEBUG on all platforms. Formerly, the UNIV_DEBUG flag might not be set for Windows platforms with Visual Studio and not on OS X with Xcode. (Bug#58279)
* InnoDB Storage Engine: In InnoDB status output, the value for I/O sum[] could be incorrect, displayed as a very large number. (Bug#57600)
* InnoDB Storage Engine: It was not possible to query the information_schema.innodb_trx table while other connections were running queries involving BLOB types. (Bug#55397)
* InnoDB Storage Engine: When the lowercase_system_names variable was set to 2, InnoDB could fail to restore a mysqldump dump of a table with foreign key constraints involving case-sensitive names. (Bug#55222)
* InnoDB Storage Engine: The OPTIMIZE TABLE statement would reset the auto-increment counter for an InnoDB table. Now the auto-increment value is preserved across this operation. (Bug#18274)
* Partitioning: A failed ALTER TABLE ... TRUNCATE PARTITION statement was still written to the binary log. (Bug#58147)
* Partitioning: Failed ALTER TABLE ... PARTITION statements could cause memory leaks. (Bug#56380)
See also Bug#46949, Bug#56996.
* 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 exceeded 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: mysqlbinlog printed USE statements to its output only when the default database changed between events. To illustrate how this could cause problems, suppose that a user issued the following sequence of statements:

CREATE DATABASE mydb;
USE mydb;
CREATE TABLE mytable (column_definitions);
DROP DATABASE mydb;
CREATE DATABASE mydb;
USE mydb;
CREATE TABLE mytable (column_definitions);

When played back using mysqlbinlog, the second CREATE TABLE statement failed with Error: No Database Selected because the second USE statement was not played back, due to the fact that a database other than mydb was never selected.
This fix insures that mysqlbinlog outputs a USE statement whenever it reads one from the binary log. (Bug#50914)
* 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:
- The error message for the master error code
- The master error code
- The error message for the slaves error code
- The slave error code
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.
* Comparisons of aggregate values with TIMESTAMP values were incorrect. (Bug#59330)
* For DIV expressions, assignment of the result to multiple variables could cause a server crash. (Bug#59241)
See also Bug#8457.
* MIN(year_col) could return an incorrect result in some cases. (Bug#59211)
* mysqlslap failed to check for a NULL return from mysql_store_result() and crashed trying to process the result set. (Bug#59109)
* In a subquery, a UNION with no referenced tables (or only a reference to the virtual table dual) did not allow an ORDER BY clause. (Bug#58970)
* Configuring MySQL with -DWITHOUT_PERFSCHEMA_STORAGE_ENGINE=1 caused build failures. (Bug#58953)
* Several Valgrind warnings were fixed. (Bug#58948, Bug#59021)
* OPTIMIZE TABLE for an InnoDB table could raise an assertion if the operation failed because it had been killed. (Bug#58933)
* If max_allowed_packet was set larger than 16MB, the server failed to reject too-large packets with “Packet too large” errors. (Bug#58887)
* A NOT IN predicate with a subquery containing a HAVING clause could retrieve too many rows, when the subquery itself returned NULL. (Bug#58818)
* EXPLAIN could crash for queries that accessed two derived tables. (Bug#58730)
* On Solaris, the MySQL build failed if it was configured with debugging enabled. (Bug#58699)
* Issuing EXPLAIN EXTENDED for a query that would use condition pushdown could cause mysqld to crash. (Bug#58553)
* An assertion could be raised for queries for which the optimizer could choose between Index Merge range access or const ref access methods. (Bug#58456)
* If MySQL was built with Visual Studio Express, the project wixca was not built. (Bug#58411)
* EXPLAIN could crash for queries that used GROUP_CONCAT(). (Bug#58396)
* 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)
* A Valgrind failure occurred in fn_format when called from archive_discover. (Bug#58205)
* CMake did not add LINK_LIBRARIES for MYSQL_ADD_PLUGIN for libmysqld. (Bug#58158)
* An assertion could be raised if the server was closing a session at the same time the session was being killed by another thread. (Bug#58136)
* Condition pushdown optimization could push down conditions with incorrect column references. (Bug#58134)
* Configuration with maintainer mode enabled resulted in errors when compiling with icc. (Bug#57991, Bug#58871)
* An ORDER BY clause was bound to the incorrect substatement when used in UNION context. (Bug#57986)
* The BIT_AND() function could return incorrect results when a join returned no matching rows. (Bug#57954)
* If the set of values aggregated with AVG(DISTINCT) contained a NULL value, the function result could be incorrect. (Bug#57932)
* In rare cases, LIKE expressions failed for an indexed column that used a collation containing contractions. (Bug#57737)
* Unnecessary subquery evaluation in contexts such as statement preparation or view creation could cause a server crash. (Bug#57703)
* View creation could produce Valgrind warnings. (Bug#57352)
* NULL geometry values could cause a crash in Item_func_spatial_collection::fix_length_and_dec. (Bug#57321)
* It was possible to compile mysqld with Performance Schema support but with a dummy atomic-operations implementation, which caused a server crash. This problem does not affect binary distributions. It is helpful as a safety measure for users who build MySQL from source. (Bug#56769)
* 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)
* After compilation from source, all header files were installed in the same directory, even those that should be installed into subdirectories of the installation include directory. (Bug#51925)
* When mysqld printed crash dump information, it incorrectly indicated that some valid pointers were invalid. (Bug#51817)
* On Mac OS X, a configuration error caused the preference pane to fail. (Bug#51264)
* On FreeBSD, if mysqld was killed with a SIGHUP signal, it could corrupt InnoDB .ibd files. (Bug#51023)
* An assertion could be raised if –1 was inserted into an AUTO_INCREMENT column by a statement writing more than one row. (Bug#50619)
* If a client supplied a user name longer than the maximum 16 characters allowed for names stored in the MySQL grant tables, all characters were being considered significant. Historically, only the first 16 characters were used to check for a match; this behavior was restored. (Bug#49752)
* The my_seek() and my_tell() functions ignored the MY_WME flag when they returned an error, which could cause client programs to hang. (Bug#48451)
* During assignment of values to system variables, legality checks on the value range occurred too late, preventing proper error checking. (Bug#43233)
* On Solaris, time-related functions such as NOW() or SYSDATE() could return a constant value. (Bug#42054)
* If the remote server for a FEDERATED table could not be accessed, queries for the INFORMATION_SCHEMA.TABLES table failed. (Bug#35333)