MySQL 5.6.36

# Functionality Added or Changed
- Replication: The functions GTID_SUBTRACT() and GTID_SUBSET() were formerly available in libmysqld only when it was built with replication support. Now these functions are always available when using this library, regardless of how it was built.
- MySQL no longer uses the default OpenSSL compression.
- There is now a distinct error code (ER_MUST_CHANGE_PASSWORD_LOGIN) for the error sent by the server to a client authenticating with an expired password.
- mysql_config_editor now supports --port and --socket options for specifying TCP/IP port number and Unix socket file name.
- mysqlcheck has a new --skip-database option. The option value is the name of a database (case sensitive) for which checks should be skipped.
- mysql_upgrade uses this option to upgrade the system tables in the mysql database before tables in other databases: It upgrade the mysql database, then all databases except the mysql database. This avoids problems that can occur if user tables are upgraded before the system tables.
- The only supported value for the innodb_mirrored_log_groups system variable is 1, so this variable is now deprecated. Setting it to 1 at startup results in a warning. Setting it to a value other than 1 at startup results in an error and the server exits. This variable will be removed in a future release.
# Bugs Fixed
- Performance; InnoDB: Switching the MySQL table used by the InnoDB memcached interface (using the @@ notation), was made more efficient, by reading cached information about the cache policy to use for each table. This optimization lets you frequently switch between tables during a session that uses the memcached interface, without incurring I/O overhead from examining table metadata each time.
- Performance; InnoDB: Performance was improved for operations on tables with many rows that were deleted but not yet purged. The speedup applies mainly to workloads that perform bulk deletes, or updates to the primary key columns, and where the system is busy enough to experience purge lag.
- Performance; InnoDB: The DROP TABLE statement for a table using compression could be slower than necessary, causing a stall for several seconds. MySQL was unnecessarily decompressing pages in the buffer pool related to the table as part of the DROP operation.
- Performance; InnoDB: The I/O routines used when the AIO subsystem were made more efficient, to merge consecutive I/O requests into a single operation. This fix solves a performance issue introduced during the 5.6 development cycle.
- Incompatible Change; Partitioning: Changes in the KEY partitioning hashing functions used with numeric, date and time, ENUM, and SET columns in MySQL 5.5 makes tables using partitioning or subpartitioning by KEY on any of the affected column types and created on a MySQL 5.5 or later server incompatible with a MySQL 5.1 server. This is because the partition IDs as calculated by a MySQL 5.5 or later server almost certainly differ from those calculated by a MySQL 5.1 server for the same table definition and data as a result of the changes in these functions.
- The principal changes in the KEY partitioning implementation in MySQL 5.5 resulting in this issue were as follows: 1. The hash function used for numeric and date and time columns changed from binary to character-based. 2. The base used for hashing of ENUM and SET columns changed from latin1 ci characters to binary.
- The fix involves adding the capability in MySQL 5.5 and later to choose which type of hashing to use for KEY partitioning, which is implemented with a new ALGORITHM extension to the PARTITION BY KEY option for CREATE TABLE and ALTER TABLE. Specifying PARTITION BY KEY ALGORITHM=1 ([columns]) causes the server to use the hashing functions as implemented in MySQL 5.1; using ALGORITHM=2 causes the server to use the hashing functions from MySQL 5.5 and later. ALGORITHM=2 is the default. Using the appropriate value for ALGORITHM, you can perform any of the following tasks:
> Create KEY partitioned tables in MySQL 5.5 and later that are compatible with MySQL 5.1, using CREATE TABLE ... PARTITION BY KEY ALGORITHM=1 (...).
> Downgrade KEY partitioned tables that were created in MySQL 5.5 or later to become compatible with MySQL 5.1, using ALTER TABLE ... PARTITION BY KEY ALGORITHM=1 (...).
> Upgrade KEY partitioned tables originally created in MySQL 5.1 to use hashing as in MySQL 5.5 and later, using ALTER TABLE ... PARTITION BY KEY ALGORITHM=2 (...).
- Important Change; Replication: Executing a statement that performs an implicit commit but whose changes are not logged when gtid_next is set to any value other than AUTOMATIC is not permitted. Now in such cases, the statement fails with an error. This includes the statements in the following list:
> CHANGE MASTER TO
> START SLAVE
> STOP SLAVE
> REPAIR TABLE
> OPTIMIZE TABLE
> ANALYZE TABLE
> CHECK TABLE
> CREATE SERVER
> ALTER SERVER
> DROP SERVER
> CACHE INDEX
> LOAD INDEX INTO CACHE
> FLUSH
> RESET
- Important Change; Replication: The version number reported by mysqlbinlog --version has been increased to 3.4.
- Important Note; Replication: It was possible to replicate from a table to a same-named view using statement-based logging, while using row-based logging instead led to a failure on the slave. Now the target object type is checked prior to performing any DML, and an error is given if the target on the slave is not actually a table. This is true regardless of the binary logging format in use.
- InnoDB: When ADD PRIMARY KEY columns are reordered in an ALTER TABLE statement (for example: ALTER TABLE t1 ADD PRIMARY KEY(a,b), CHANGE a a INT AFTER b), the log apply for UPDATE operations would fail to find rows.
- InnoDB: ALTER TABLE operations on InnoDB tables that added a PRIMARY KEY using a column prefix could produce an incorrect result.
- InnoDB: For ALTER TABLE operations on InnoDB tables that required a table-copying operation, other transactions on the table might fail during the copy. However, if such a transaction issued a partial rollback, the rollback was treated as a full rollback.
- InnoDB: When parsing a delimited search string such as “abc-def” in a full-text search, InnoDB now uses the same word delimiters as MyISAM.
- InnoDB: This fix improves code readability by addressing naming inconsistencies for InnoDB PERFORMANCE_SCHEMA key declarations.
- InnoDB: This fix disables a condition for extra splitting of clustered index leaf pages, on compressed tables. Extra page splitting was only done to reserve space for future updates, so that future page splits could be avoided.
- InnoDB: For InnoDB tables, if a PRIMARY KEY on a VARCHAR column (or prefix) was empty, index page compression could fail.
- InnoDB: Status values in the INNODB_FT_CONFIG table would not update. The INNODB_FT_CONFIG is intended for internal configuration and should not be used for statistical information purposes. To avoid confusion, column values that are intended for internal use have been removed from the INNODB_FT_CONFIG table. This fix also removes the INNODB_FT_INSERTED table and other internal full text search-related tables that were unintentionally exposed.
- InnoDB: With innodb_api_enable_mdl=OFF, an ALTER TABLE operation on an InnoDB table that required a table copy could cause a server exit.
- InnoDB: Improper testing of compatibility between the referencing and referenced during ALTER TABLE ... ADD FOREIGN key could cause a server exit.
- InnoDB: Rollback did not include changes made to temporary tables by read-only transactions.
- InnoDB: The InnoDB page-splitting algorithm could recurse excessivly.
- InnoDB: For debug builds, InnoDB status exporting was subject to a race condition that could cause a server exit.
- InnoDB: When using ALTER TABLE to set an AUTO_INCREMENT column value to a user-specified value, InnoDB would set the AUTO_INCREMENT value to the user-specified value even when the AUTO_INCREMENT value is greater than the user-specified value. This fix ensures that the AUTO_INCREMENT value is set to the maximum of the user-specified value and MAX(auto_increment_column)+1, which is the expected behaviour.
- InnoDB: Importing a tablespace with the configuration file present would not import the data file. This problem would occur when all pages are not flushed from the buffer pool after a table is altered using the copy and rename approach. This fix ensures that all pages are flushed from the buffer pool when a table is altered using the copy and rename approach.
- InnoDB: RENAME TABLE would result in a hang due to a MySQL mutex acquisition deadlock.
- InnoDB: Internal read operations could be misclassified as synchronous when they were actually asynchronous. When the I/O requests returned sooner than expected, threads could be scheduled inefficiently. This issue mainly affected read-ahead requests, and thus had relatively little impact on I/O performed by user queries.
- InnoDB: The lock_validate function, which is only present in debug builds, acquired and released mutexes to avoid hogging them. This behavior introduced a window wherein changes to the hash table could occur while code traversed the same set of data. This fix updates lock_validate logic to collect all records for which locks must be validated, releases mutexes, and runs a loop to validate record locks.
- InnoDB: ALTER TABLE functions would perform a check to see if InnoDB is in read-only mode (srv_read_only_mode=true). If InnoDB was in read-only mode, the check would return a successful status and do nothing else. This fix replaces srv_read_only_mode check conditions with debug assertions.
- InnoDB: An improper call to abort() by InnoDB could result in a server exit.
- InnoDB: When the InnoDB buffer pool is almost filled with 4KB compressed pages, inserting into 16KB compact tables would cause 8KB pages_free to increase, which could potentially slow or stall inserts.
- InnoDB: An assertion failure would occur in heap->magic_n == MEM_BLOCK_MAGIC_N due to a race condition that appeared when row_merge_read_clustered_index() returned an error.
- InnoDB: This fix removes an unnecessary debug assertion related to page_hash locks which only affects debug builds. The debug assertion is no longer valid and should have been removed when hash_lock array was introduced in MySQL 5.6.
- InnoDB: The InnoDB memcached plugin could encounter a serious error under a heavy load, such as produced by benchmark runs.
- InnoDB: If the MySQL server halted at a precise moment when a purge operation was being applied from the change buffer, the operation could be incorrectly performed again during the next restart. A workaround was to set the configuration option innodb_change_buffering=changes, to turn off change buffering for purge operations.
- InnoDB: When InnoDB locking code was revised, a call to register lock waits was inadvertently removed. This fix adds the call back to the InnoDB locking code.
- InnoDB: A direct call to the trx_start_if_not_started_xa_low() function would cause a debug assertion.
- InnoDB: In the case of LOCK WAIT for an insert in a foreign key table, InnoDB could report a false dictionary-changed error and cause the insert to fail rather than being retried.
- InnoDB: In some cases, deadlock detection did not work, resulting in sessions hanging waiting for a lock-wait timeout.
- InnoDB: An in-place ALTER TABLE on an InnoDB table could fail to delete the statistics for the old primary key from the mysql.innodb_index_stats table.
- InnoDB: This fix updates InnoDB code in ha_innodb.cc and handler0alter.cc to use TABLE::key_info instead of both TABLE::key_info and TABLE_SHARE::key_info.
- InnoDB: Arithmetic underflow during page compression for CREATE TABLE on an InnoDB table could cause a server exit.
- InnoDB: For debug builds, online ALTER TABLE operations for InnoDB tables could cause a server exit during table rebuilding.
- InnoDB: In some cases, the InnoDB purge coordinator did not use all available purge threads, resulting in suboptimal purge activity.
- InnoDB: On systems that cannot handle unaligned memory access, depending on the stack frame alignment, a SIGBUS error could occur during startup. This issue was observed on Solaris 64-bit systems.
- InnoDB: ALTER TABLE for InnoDB tables was not fully atomic.
- InnoDB: When innodb_mirrored_log_groups was set to a value other than the default 1, the MySQL server encountered a serious error during startup while loading the InnoDB memcached plugin. In earlier releases, the server would refuse to start (but not display an error) when this setting was changed. This fix cleans up the error handling for unsupported values of this configuration option.
- InnoDB: An error at the filesystem level, such as too many open files, could cause an unhandled error during an ALTER TABLE operation. The error could be accompanied by Valgrind warnings, and by this assertion message:
>Assertion `! is_set()' failed.
mysqld got signal 6 ;
- InnoDB: The INNODB_SYNC_ARRAY_SIZE variable was incorrectly allowed to be configured at runtime. As documented, INNODB_SYNC_ARRAY_SIZE must be configured when the MySQL instance is starting up, and cannot be changed afterward. This fix changes INNODB_SYNC_ARRAY_SIZE to a non-dynamic variable, as intended.
- InnoDB: The server could exit during an attempt by InnoDB to reorganize or compress a compressed secondary index page.
- InnoDB: A RENAME TABLE statement could stall for several minutes before timing out. This issue could occurred for a table using compression, with change buffering enabled.
- InnoDB: A DML operation performed while a RENAME TABLE operation waits for pending I/O operations on the tablespace to complete would result in a deadlock.
- InnoDB: If the server was started with the skip-innodb option, or InnoDB otherwise failed to start, query any of these Information Schema tables would cause a severe error:
> INNODB_BUFFER_PAGE
> INNODB_BUFFER_PAGE_LRU
> NNODB_BUFFER_POOL_STATS
- InnoDB: Online DDL had a restriction that prevented renaming a column and adding a foreign key involving that column in a single ALTER TABLE statement. Now, this combination of operations is allowed in a single statement.
- InnoDB: When printing out long semaphore wait diagnostics, sync_array_cell_print() ran into a segmentation violation (SEGV) caused by a race condition. This fix addresses the race condition by allowing the cell to be freed while it is being printed.
- InnoDB: The value of the innodb_version variable was not updated consistently for all server releases for the InnoDB Plugin in MySQL 5.1, and the integrated InnoDB component in MySQL 5.5, 5.6, and higher. Since InnoDB and MySQL Server development cycles are fully integrated and synchronized, now the value returned by the innodb_version variable is the same as for the version variable.
- InnoDB: Killing a query caused an InnoDB assertion failure when the same table (cursor) instance was used again. This is the result of a regression error introduced . The fix introduced a check to handle kill signals for long running queries but the cursor was not restored to the proper state.
- InnoDB: On startup, InnoDB reported a message on 64-bit Linux and 64-bit Windows systems stating that the CPU does not support crc32 instructions. On Windows, InnoDB does not use crc32 instructions even if supported by the CPU. This fix revises the wording of the message and implements a check for availability of crc32 instructions.
- InnoDB: The length of internally generated foreign key names was not checked. If internally generated foreign key names were over the 64 character limit, this resulted in invalid DDL from SHOW CREATE TABLE. This fix checks the length of internally generated foreign key names and reports an error message if the limit is exceeded.
- InnoDB: This fix removes left-over prototype code for srv_parse_log_group_home_dirs, and related header comments.
- InnoDB: Attempting to replace the default InnoDB FTS stopword list by creating an InnoDB table with the same structure as INFORMATION_SCHEMA.innodb_ft_default_stopword would result in an error. SHOW CREATE TABLE revealed that the new InnoDB table was created with CHARSET=utf8. The InnoDB FTS stopword table validity check only supported latin1. This fix extends the validity check for all supported character sets.
- Partitioning: ALGORITHM = INPLACE, which was disallowed in MySQL 5.6.10 for DDL statements operating on partitioned tables, can once again be used with such statements.
- Partitioning: A query on a table partitioned by range and using TO_DAYS() as a partitioing function always included the first partition of the table when pruning. This happened regardless of the range employed in the BETWEEN clause of such a query.
- Partitioning: Execution of ALTER TABLE ... DROP PARTITION against a view caused the server to crash, rather than fail with an error as expected.
- Partitioning: A query result was not sorted if both DISTINCT and ORDER BY were used and the underlying table was partitioned.
- Partitioning: Inserting any number of rows into an ARCHIVE table that used more than 1000 partitions and then attempting to drop the table caused the MySQL Server to fail.
- Replication: When using GTIDs and binary log auto-positioning, the master had to scan all binary logs whenever the slave reconnected (due to reasons such as I/O thread failure or a change of master) before it could send any events to slave. Now, the master starts from the oldest binary log that contains any GTID not found on the slave.
- Replication: When the server version of the master was greater than or equal to 10, replication to a slave having a lower server version failed.
- Replication: When replicating to a MySQL 5.6 master to an older slave, Error 1193 (ER_UNKNOWN_SYSTEM_VARIABLE) was logged with a message such as Unknown system variable 'SERVER_UUID' on master, maybe it is a *VERY OLD MASTER*. This message has been improved to include more information, similar to this one: Unknown system variable 'SERVER_UUID' on master. A probable cause is that the variable is not supported on the master (version: 5.5.31), even though it is on the slave (version: 5.6.11).
- Replication: A zero-length name for a user variable (such as @``) was incorrectly considered to be a sign of data or network corruption when reading from the binary log.
- Replication: When MTS is on and transactions are being applied, the slave coordinator would hang when encountering a checksum error on a transaction event. This was due to a deadlock situation in which the coordinator assumed a normal stop while a worker waited for the coordinator to dispatch more events. For debug builds, the problem appeared as an assertion failure, which was due to the coordinator not setting thd->is_error() when encountering an error.
- Replication: mysqlbinlog can connect to a remote server and read its binary logs. In MySQL 5.6 and later, this tool can also wait for the server to generate and send additional events, in practice behaving like a slave connecting to a master. In cases where the server sent a heartbeat, mysqlbinlog was unable to handle it properly. As a consequence, mysqlbinlog failed at this point, without reading any more events from the server. To fix this problem, mysqlbinlog now ignores any binary log events of type HEARTBEAT_LOG_EVENT that it receives.
- Replication: STOP SLAVE could cause a deadlock when issued concurrently with a statement such as SHOW STATUS that retrieved the values for one or more of the status variables Slave_retried_transactions, Slave_heartbeat_period, Slave_received_heartbeats, Slave_last_heartbeat, or Slave_running.
- Replication: Using the --replicate-* options (see Replication Slave Options and Variables) could in some cases lead to a memory leak on the slave.
- Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on the slave.
- Replication: The session-level value for gtid_next was incorrectly reset on the slave for all rollbacks, which meant that GTIDs could be lost for multi-statement transactions, causing the slave to stop with an ER_GTID_NEXT_TYPE_UNDEFINED_GROUP error. Now this is done only when a complete transaction is being rolled back, or when autocommit is enabled.
- Replication: In order to provision or to restore a server using GTIDs, it is possible to set gtid_purged to a given GTID set listing the transactions that were imported. This operation requires that the global gtid_executed and gtid_purged server system variables are empty. (This is done in order to avoid the possibility of overriding server-generated GTIDs.)
- The error message GTID_PURGED can only be set when GTID_EXECUTED is empty that was raised when this requirement was not met could be confusing or misleading because it did not specify the scope of the affected variables. To prevent this from happening, error messages that refer to variables relating to GTIDs now specify the scope of any such variables when they do so.
- Replication: In certain cases, the dump thread could send a heartbeat out of synchronisation with format description events. One of the effects of this issue what that, after provisioning a new server from a backup data directory and setting --gtid-mode=ON and enabling autopositioning (see CHANGE MASTER TO Syntax), replication failed to start, with the error Read invalid event from master.... The same problem could also cause GTID-based replication to fail due to skipped events following a unplanned shutdown of the master.
- Replication: In some cases, when the slave could not recognize the server version of the master, this could cause the slave to fail.
- Replication: Table IDs used in replication were defined as type ulong on the master and uint on the slave. In addition, the maximum value for table IDs in binary log events is 6 bytes (281474976710655). This combination of factors led to the following issues:
> Data could be lost on the slave when a table was assigned an ID greater than uint.
> Table IDs greater than 281474976710655 were written to the binary log as 281474976710655.
> This led to a stopped slave when the slave encountered two tables having the same table ID.
- To fix these problems, IDs are now defined by both master and slave as type ulonglong but constrained to a range of 0 to 281474976710655, restarting from 0 when it exceeds this value.
- Replication: Internal objects used for relay log information were only partially deleted before freeing their memory.
- Replication: It was possible in certain cases—immediately after detecting an EOF in the dump thread read event loop, and before deciding whether to change to a new binary log file—for new events to be written to the binary log before this decision was made. If log rotation occurred at this time, any events that occurred following EOF detection were dropped, resulting in loss of data. Now in such cases, steps are taken to make sure that all events are processed before allowing the log rotation to take place.
- Replication: If the disk becomes full while writing to the binary log, the server hangs until space is freed up manually. It was possible after this was done for the MySQL server to fail, due to an internal status value being set when not needed. Now in such cases, rather than trying to set this status, a warning is written in the error log instead.
- Microsoft Windows: In Shared Memory mode, the MySQL Server could crash when receiving requests from multiple threads.
- Failure to handle a full-text search wildcard properly could cause the server to exit.
- InnoDB now reports row and table locks to the thread pool plugin. Deadlocks within a thread group could occur otherwise.
- SHOW ENGINE PERFORMANCE_SCHEMA STATUS could report incorrect memory-allocation values when the correct values exceeded 4GB.
- Performance Schema statement tokenization overhead was reduced.
- A long database name in a GRANT statement could cause the server to exit.
- On Linux, a race condition involving epoll() could cause the thread pool plugin to miss events. This was most likely on systems with greater than 16 cores.
- The server could exit if a prepared statement attempted to create a table using the name of an existing view while an SQL handler was opened.
- For debug builds, checking of password constraints could raise an assertion for statements that updated passwords.
- The BUILD-CMAKE file in MySQL distributions was updated with the correct URL for CMake information.
- A Valgrind failure could occur if a CREATE USER statement was logged to the general query log and the old_passwords system variable was set to 2.
- The optimizer's attempt to remove redundant subquery clauses raised an assertion when executing a prepared statement with a subquery in the ON clause of a join in a subquery.
- Very small join_buffer_size values could cause an assertion to be raised.
- Some aggregate queries attempted to allocate excessive memory.
- Incorrect results were returned if a query contained a subquery in an IN clause which contained an XOR operation in the WHERE clause.
- For debug builds, an assertion could be raised if a statement failed with autocommit enabled just before an XA START statement was issued.
- Conversion of numeric values to BIT could yield unexpected results.
- Certain legal HAVING clauses were rejected as invalid.
- Fixed warnings when compiling with XCode 4.6. Fixed warnings when compiling when the _XOPEN_SOURCE or isoctal macro was already defined in the environment.
- Queries using range predicates that were evaluated using the LooseScan semi-join strategy could return duplicate rows.
- For upgrade operations, RPM packages produced unnecessary errors about being unable to access .err files.
- In the range optimizer, an index merge failure could cause a server exit.
- A full-text query using Boolean mode could return zero results in some cases where the search term was a quoted phrase:
- If the quoted phrase was preceded by a + sign. For example, this combination of a Boolean + operator and a phrase would return zero results:
where match(content) against('+"required term due to plus sign"' in boolean mode)
If the quoted phrase contained any stopwords. For example, the stopword "the" inside the phrase caused the query to return zero results:
where match(content) against('"stopword inside the phrase"' in boolean mode)
- For debug builds, the server could exit due to incorrect calculation of applicable indexes for a join that involved const tables.
- A bug in range optimization sometimes led to incorrect condition calculation for index merge union. This could lead to missing rows.
- The Performance Schema could return incorrect values for the PROCESSLIST_INFO column of the threads table.
- Invocation of the range optimizer for a NULL select caused the server to exit.
- mysql_config --libs displayed incorrect output.
- For a CREATE TABLE (... col_name TIMESTAMP DEFAULT CURRENT_TIMESTAMP ...) ... SELECT statement for which the SELECT did not provide a value for the TIMESTAMP column, that column was set to '0000-00-00 00:00:00', not the current timestamp.
- yaSSL did not perform proper padding checks, but instead examined only the last byte of plaintext and used it to determine how many bytes to remove.
- Using GROUP BY WITH ROLLUP in a prepared statement could cause the server to exit.
- If, in a SELECT, the HAVING clause contained a function call which itself contained an alias to a selected expression, the server could sometimes exit.
- Setting the slave_rows_search_algorithms system variable to an inappropriate value could cause the server to exit.
- Directory name manipulation could result in stack overflow on Mac OS X and Windows.
- with statement-based binary logging, dropping a TEMPORARY InnoDB table could cause a segmentation fault.
- For debug builds, if the server was started with binary logging disabled, executing SHOW RELAYLOG EVENTS from within a stored procedure raised an assertion.
- The query parser leaked memory for some syntax errors.
- With the thread pool plugin enabled, large numbers of connections could lead to a Valgrind panic or failure of clients to be able to connect.
- The server executed EXPLAIN FORMAT=JSON for some malformed queries improperly.
- Performance Schema instrumentation was missing for slave worker threads.
- The initial test database contained a dummy.bak file that prevented DROP DATABASE from working. This file is no longer included. Also, a db.opt file is now included that contains these lines:
> default-character-set=latin1
> default-collation=latin1_swedish_ci
- Setting a system variable to DEFAULT could cause the server to exit.
- SET PASSWORD and GRANT ... IDENTIFIED BY have no effect on the password of a user who is authenticated using an authentication plugin that accesses passwords stored externally to the mysql.user table. But attempts to change the password of such a user produced no warning, leading to the impression that the password had been changed when it was not. Now MySQL issues an ER_SET_PASSWORD_AUTH_PLUGIN warning to indicate that the attempt was ignored.
- For debug builds, creating an InnoDB table in strict SQL mode that violated the maximum key length limit caused the server to exit.
- Issuing a PREPARE statement using certain combinations of stored functions and user variables caused the server to exit.
- Joins of exactly 32 tables and containing a HAVING clause returned an empty result.
- A mysys library string-formatting routine could mishandle width specifiers.
- The --character-set-server option could set connection character set system variables to values such as ucs2 that are not permitted.
- During shutdown, the server could attempt to lock an uninitialized mutex.
- The --default-authentication-plugin option permitted invalid plugin values, and did not always set the old_passwords system variable to a value appropriate for the named plugin.
- Under some circumstances, mysql --secure-auth permitted passwords to be sent to the server using the old (pre-4.1) hashing format.
- With index condition pushdown enabled, queries for which the pushed-down condition contained no columns in the used index could be slow.
- Table creation operations added entries to the Performance Schema file_instances table, but these were not always removed for table drop operations.
- In special cases, the optimizer did not consider indexes that were applicable to query processing, resulting in potentially suboptimal execution and incorrect EXPLAIN output.
- A query with an EXISTS/IN/ALL/ANY subquery with an ORDER BY clause ordering by an outer column of type BLOB that is not in the select list caused an assertion to fire.
- Creating an InnoDB table with a FULLTEXT index could encounter a serious error if the table name contained nonalphanumeric characters.
- Enabling the query cache during high client contention could cause the server to exit.
- The server sometimes failed to respect MAX_CONNECTIONS_PER_HOUR limits on user connections.
- The optimizer could return incorrect results after transforming an IN subquery with aggregate functions to an EXISTS subquery.
- When a client program loses the connection to the MySQL server or if the server begins a shutdown after the client has executed mysql_stmt_prepare(), the next mysql_stmt_prepare() returns an error (as expected) but subsequent mysql_stmt_execute() calls crash the client.
- Previously, if multiple --login-path options were given, mysql_config_editor ignored all but the last one. Now multiple --login-path options result in an error.
- SET PASSWORD for anonymous users did not work correctly.
- SHOW COLUMNS on a view defined as a UNION of Geometry columns could cause the server to exit.
- The sha256_password_private_key_path and sha256_password_public_key_path system variables indicate key files for the sha256_password authentication plugin, but the server failed to properly check whether the key files were valid. Now in the event that either key file is invalid, the server logs an error and exits.
- SET var_name = VALUES(col_name) could cause the server to exit. This syntax is now prohibited because in SET context there is no column name and the statement returns ER_BAD_FIELD_ERROR.
- The COM_CHANGE_USER command in the client/server protocol did not properly use the character set number in the command packet, leading to incorrect character set conversion of other values in the packet.
- Invoking the FORMAT() function with a locale and a very large number could cause the server to exit.
- yaSSL rejected some valid server SSL certificates.
- Certain plugin-related conditions can make a user account unusable:
> The account requires an authentication plugin that is not loaded.
> The account requires the sha256_password authentication plugin but the server was started with neither SSL nor RSA enabled as required by this plugin.
- The server now checks those conditions by default and produces warnings for unusable accounts. This checking slows down server initialization and FLUSH PRIVILEGES, so it is made optional by means of the new validate_user_plugins system variable. This variable is enabled by default, but if you do not require the additional checking, you can disable it at startup to avoid the performance decrement.
- Passing an unknown time zone specification to CONVERT_TZ() resulted in a memory leak.
- The obsolete linuxthreads.txt and glibc-2.2.5.patch files in the Docs directory of MySQL distributions have been removed.
- mysql_install_db did not escape '_' in the host name for statements written to the grant tables.
- mysqld_safe used the nonportable -e test construct.
- An out-of-memory condition could occur while handling an out-of-memory error, leading to recursion in error handling.
- The optimizer used loose index scan for some queries for which this access method is inapplicable.
- If a dump file contained a view with one character set and collation defined on a view with a different character set and collation, attempts to restore the dump file failed with an “illegal mix of collations” error.
- The REPLACE() function produced incorrect results when a user variable was supplied as an argument and the operation was performed on multiple rows.
- UNION type conversion could incorrectly turn unsigned values into signed values.
- UNION ALL on BLOB columns could produce incorrect results.
- View access in low memory conditions could raise a debugging assertion.
- Queries with many values in a IN() clause were slow due to inclusion of debugging code in non-debugging builds.
- Setting max_connections to a value less than the current number of open connections caused the server to exit.
- Some table I/O performed by the server when calling a storage engine were missing from the statistics collected by the Performance Schema.
- For debug builds, some queries with SELECT ... FROM DUAL nested subqueries raised an assertion.
- Nonspatial indexes only support exact-match lookups for spatial columns, but the optimizer incorrectly used range access in some cases, leading to incorrect results.
- If mysql is built with the bundled libedit library, the library is built as static code, to avoid linking to a different dynamic version at runtime. Dynamic linking could result in use of a different, incompatible version and a segmentation fault.
- The --log-slow-admin-statements and --log-slow-slave-statements command options now are exposed at runtime as the log_slow_admin_statements and log_slow_slave_statements system variables. Their values can be examined using SHOW VARIABLES. The variables are dynamic, so their values can can be set at runtime. (The options were actually replaced by the system variables, but as system variables can be set at server startup, no option functionality is lost.)
- For arguments with fractional seconds greater than six decimals, SEC_TO_TIME() truncated, rather than rounding as it should have.
- MySQL failed to build if configured with WITH_LIBWRAP enabled.
- If the server was started without a --datadir option, SHOW VARIABLES could show an empty value for the datadir system variable.
- Configuring with -DWITH_SSL=/path/to/openssl resulted in link errors due to selection of the incorrect libcrypto.
- ALTER TABLE tbl_name ADD COLUMN col_name TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP inserted 0000-00-00 00:00:00 rather than the current timestamp if the alteration was done in place rather than by making a table copy.
- If the server was started with --skip-grant-tables, ALTER USER ... PASSWORD EXPIRE caused the server to exit.
- CMake did not check whether the system zlib had certain functions required for MySQL, resulting in build errors. Now it checks and falls back to the bundled zlib if the functions are missing.
- mysql_install_db did not work in Solaris 10 sparse root zones.
- or EXPLAIN DELETE and EXPLAIN UPDATE the possible_keys column listed all indexes, not just the applicable indexes.
- The Perl version of mysql_install_db mishandled some error messages.
- Handling of SQL_CALC_FOUND_ROWS in combination with ORDER BY and LIMIT could lead to incorrect results for FOUND_ROWS().
- Adding an ORDER BY clause following an IN subquery could cause duplicate rows to be returned.
- If INET6_NTOA() or INET6_ATON() returned NULL for a row in a result set, following rows also returned NULL.
- A statement with an aggregated, nongrouped outer query and an aggregated, nongrouped subquery in the SELECT list could return incorrect results.
- With explicit_defaults_for_timestamp enabled, inserting NULL into a TIMESTAMP NOT NULL column now produces an error (as it already did for other NOT NULL data types), instead of inserting the current timestamp.

# Functionality Added or Changed
* MySQL no longer uses the default OpenSSL compression.
# Bugs Fixed
* Performance; InnoDB: Performance was improved for operations on tables with many rows that were deleted but not yet purged. The speedup applies mainly to workloads that perform bulk deletes, or updates to the primary key columns, and where the system is busy enough to experience purge lag.
* Performance; InnoDB: The DROP TABLE statement for a table using compression could be slower than necessary, causing a stall for several seconds. MySQL was unnecessarily decompressing pages in the buffer pool related to the table as part of the DROP operation.
* Incompatible Change; Partitioning: Changes in the KEY partitioning hashing functions used with numeric, date and time, ENUM, and SET columns in MySQL 5.5 makes tables using partitioning or subpartitioning by KEY on any of the affected column types and created on a MySQL 5.5 or later server incompatible with a MySQL 5.1 server. This is because the partition IDs as calculated by a MySQL 5.5 or later server almost certainly differ from those calculated by a MySQL 5.1 server for the same table definition and data as a result of the changes in these functions.
* The principal changes in the KEY partitioning implementation in MySQL 5.5 resulting in this issue were as follows:
- The hash function used for numeric and date and time columns changed from binary to character-based.
- The base used for hashing of ENUM and SET columns changed from latin1 ci characters to binary.
- The fix involves adding the capability in MySQL 5.5 and later to choose which type of hashing to use for KEY partitioning, which is implemented with a new ALGORITHM extension to the PARTITION BY KEY option for CREATE TABLE and ALTER TABLE. Specifying PARTITION BY KEY ALGORITHM=1 ([columns]) causes the server to use the hashing functions as implemented in MySQL 5.1; using ALGORITHM=2 causes the server to use the hashing functions from MySQL 5.5 and later. ALGORITHM=2 is the default. Using the appropriate value for ALGORITHM, you can perform any of the following tasks:
> Create KEY partitioned tables in MySQL 5.5 and later that are compatible with MySQL 5.1, using CREATE TABLE ... PARTITION BY KEY ALGORITHM=1 (...).
> Downgrade KEY partitioned tables that were created in MySQL 5.5 or later to become compatible with MySQL 5.1, using ALTER TABLE ... PARTITION BY KEY ALGORITHM=1 (...).
> Upgrade KEY partitioned tables originally created in MySQL 5.1 to use hashing as in MySQL 5.5 and later, using ALTER TABLE ... PARTITION BY KEY ALGORITHM=2 (...).
- Important: After such tables are upgraded, they cannot be used any longer with MySQL 5.1 unless they are first downgraded again using ALTER TABLE ... PARTITION BY KEY ALGORITHM=1 (...) on a MySQL server supporting this option.
* Important Note; Replication: It was possible to replicate from a table to a same-named view using statement-based logging, while using row-based logging instead led to a failure on the slave. Now the target object type is checked prior to performing any DML, and an error is given if the target on the slave is not actually a table. This is true regardless of the binary logging format in use.
* InnoDB: For InnoDB tables, if a PRIMARY KEY on a VARCHAR column (or prefix) was empty, index page compression could fail.
* InnoDB: For debug builds, InnoDB status exporting was subject to a race condition that could cause a server exit.
* InnoDB: RENAME TABLE would result in a hang due to a MySQL mutex acquisition deadlock.
* InnoDB: Internal read operations could be misclassified as synchronous when they were actually asynchronous. When the I/O requests returned sooner than expected, threads could be scheduled inefficiently. This issue mainly affected read-ahead requests, and thus had relatively little impact on I/O performed by user queries.
* InnoDB: An improper call to abort() by InnoDB could result in a server exit.
* InnoDB: If the MySQL server halted at a precise moment when a purge operation was being applied from the change buffer, the operation could be incorrectly performed again during the next restart. A workaround was to set the configuration option innodb_change_buffering=changes, to turn off change buffering for purge operations.
* InnoDB: Arithmetic underflow during page compression for CREATE TABLE on an InnoDB table could cause a server exit.
* InnoDB: If the server was started with the skip-innodb option, or InnoDB otherwise failed to start, query any of these Information Schema tables would cause a severe error:
- INNODB_BUFFER_PAGE
- INNODB_BUFFER_PAGE_LRU
- INNODB_BUFFER_POOL_STATS
* InnoDB: When printing out long semaphore wait diagnostics, sync_array_cell_print() ran into a segmentation violation (SEGV) caused by a race condition. This fix addresses the race condition by allowing the cell to be freed while it is being printed.
* InnoDB: Killing a query caused an InnoDB assertion failure when the same table (cursor) instance was used again. This is the result of a regression error introduced. The fix introduced a check to handle kill signals for long running queries but the cursor was not restored to the proper state.
* InnoDB: The length of internally generated foreign key names was not checked. If internally generated foreign key names were over the 64 character limit, this resulted in invalid DDL from SHOW CREATE TABLE. This fix checks the length of internally generated foreign key names and reports an error message if the limit is exceeded.
* Partitioning: A query on a table partitioned by range and using TO_DAYS() as a partitioing function always included the first partition of the table when pruning. This happened regardless of the range employed in the BETWEEN clause of such a query.
* Partitioning: Execution of ALTER TABLE ... DROP PARTITION against a view caused the server to crash, rather than fail with an error as expected.
* Replication: A zero-length name for a user variable (such as @``) was incorrectly considered to be a sign of data or network corruption when reading from the binary log.
* Replication: Using the --replicate-* options (see Replication Slave Options and Variables) could in some cases lead to a memory leak on the slave.
* Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on the slave.
* Replication: It was possible in certain cases—immediately after detecting an EOF in the dump thread read event loop, and before deciding whether to change to a new binary log file—for new events to be written to the binary log before this decision was made. If log rotation occurred at this time, any events that occurred following EOF detection were dropped, resulting in loss of data. Now in such cases, steps are taken to make sure that all events are processed before allowing the log rotation to take place.
* SHOW ENGINE PERFORMANCE_SCHEMA STATUS could report incorrect memory-allocation values when the correct values exceeded 4GB.
* A long database name in a GRANT statement could cause the server to exit.
* On Linux, a race condition involving epoll() could cause the thread pool plugin to miss events. This was most likely on systems with greater than 16 cores.
* The server could exit if a prepared statement attempted to create a table using the name of an existing view while an SQL handler was opened.
* Incorrect results were returned if a query contained a subquery in an IN clause which contained an XOR operation in the WHERE clause.
* For upgrade operations, RPM packages produced unnecessary errors about being unable to access .err files.
* Invocation of the range optimizer for a NULL select caused the server to exit.
* yaSSL did not perform proper padding checks, but instead examined only the last byte of plaintext and used it to determine how many bytes to remove.
* With the thread pool plugin enabled, large numbers of connections could lead to a Valgrind panic or failure of clients to be able to connect.
* The initial test database contained a dummy.bak file that prevented DROP DATABASE from working. This file is no longer included. Also, a db.opt file is now included that contains these lines:
- default-character-set=latin1
- default-collation=latin1_swedish_ci
* Setting a system variable to DEFAULT could cause the server to exit.
* Issuing a PREPARE statement using certain combinations of stored functions and user variables caused the server to exit.
* Contention in the thread pool during kill processing could lead to a Valgrind panic.
* When a client program loses the connection to the MySQL server or if the server begins a shutdown after the client has executed mysql_stmt_prepare(), the next mysql_stmt_prepare() returns an error (as expected) but subsequent mysql_stmt_execute() calls crash the client.
* SHOW COLUMNS on a view defined as a UNION of Geometry columns could cause the server to exit.
* A LIKE pattern with too many '%' wildcards could cause a segmentation fault.
* SET var_name = VALUES(col_name) could cause the server to exit. This syntax is now prohibited because in SET context there is no column name and the statement returns ER_BAD_FIELD_ERROR.
* The COM_CHANGE_USER command in the client/server protocol did not properly use the character set number in the command packet, leading to incorrect character set conversion of other values in the packet.
* Subqueries with OUTER JOIN could return incorrect results if the subquery referred to a column from another SELECT.
* On Microsoft Windows, the MSI package would now allow a license switch (community to or from the commercial edition) when the switched MySQL Server versions were identical.
* mysql_install_db did not escape '_' in the host name for statements written to the grant tables.
* An out-of-memory condition could occur while handling an out-of-memory error, leading to recursion in error handling.
* The optimizer used loose index scan for some queries for which this access method is inapplicable.
* If a dump file contained a view with one character set and collation defined on a view with a different character set and collation, attempts to restore the dump file failed with an “illegal mix of collations” error.
* The REPLACE() function produced incorrect results when a user variable was supplied as an argument and the operation was performed on multiple rows.
* UNION ALL on BLOB columns could produce incorrect results.
* View access in low memory conditions could raise a debugging assertion.
* Setting max_connections to a value less than the current number of open connections caused the server to exit.
* Incorrect metadata could be produced for columns returned from some views.
* For debug builds, some queries with SELECT ... FROM DUAL nested subqueries raised an assertion.
* If the server was started without a --datadir option, SHOW VARIABLES could show an empty value for the datadir system variable.
* CMake did not check whether the system zlib had certain functions required for MySQL, resulting in build errors. Now it checks and falls back to the bundled zlib if the functions are missing.

# Functionality Added or Changed
* MySQL no longer uses the default OpenSSL compression.
# Bugs Fixed
* Performance; InnoDB: The DROP TABLE statement for a table using compression could be slower than necessary, causing a stall for several seconds. MySQL was unnecessarily decompressing pages in the buffer pool related to the table as part of the DROP operation.
* Important Note; Replication: It was possible to replicate from a table to a same-named view using statement-based logging, while using row-based logging instead led to a failure on the slave. Now the target object type is checked prior to performing any DML, and an error is given if the target on the slave is not actually a table. This is true regardless of the binary logging format in use.
* InnoDB: For InnoDB tables, if a PRIMARY KEY on a VARCHAR column (or prefix) was empty, index page compression could fail.
* InnoDB: For debug builds, InnoDB status exporting was subject to a race condition that could cause a server exit.
* InnoDB: Arithmetic underflow during page compression for CREATE TABLE on an InnoDB table could cause a server exit.
* InnoDB: This fix makes MySQL more responsive to KILL QUERY statements when the query is accessing an InnoDB table.
* InnoDB: When printing out long semaphore wait diagnostics, sync_array_cell_print() ran into a segmentation violation (SEGV) caused by a race condition. This fix addresses the race condition by allowing the cell to be freed while it is being printed.
* InnoDB: Killing a query caused an InnoDB assertion failure when the same table (cursor) instance was used again. This is the result of a regression error introduced. The fix introduced a check to handle kill signals for long running queries but the cursor was not restored to the proper state.
* InnoDB: The length of internally generated foreign key names was not checked. If internally generated foreign key names were over the 64 character limit, this resulted in invalid DDL from SHOW CREATE TABLE. This fix checks the length of internally generated foreign key names and reports an error message if the limit is exceeded.
* Partitioning: A query on a table partitioned by range and using TO_DAYS() as a partitioing function always included the first partition of the table when pruning. This happened regardless of the range employed in the BETWEEN clause of such a query.
* Replication: A zero-length name for a user variable (such as @``) was incorrectly considered to be a sign of data or network corruption when reading from the binary log.
* Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on the slave.
* Replication: It was possible in certain cases—immediately after detecting an EOF in the dump thread read event loop, and before deciding whether to change to a new binary log file—for new events to be written to the binary log before this decision was made. If log rotation occurred at this time, any events that occurred following EOF detection were dropped, resulting in loss of data. Now in such cases, steps are taken to make sure that all events are processed before allowing the log rotation to take place.
* A long database name in a GRANT statement could cause the server to exit.
* Incorrect results were returned if a query contained a subquery in an IN clause which contained an XOR operation in the WHERE clause.
* Invocation of the range optimizer for a NULL select caused the server to exit.
* yaSSL did not perform proper padding checks, but instead examined only the last byte of plaintext and used it to determine how many bytes to remove.
* SHOW COLUMNS on a view defined as a UNION of Geometry columns could cause the server to exit.
* A LIKE pattern with too many '%' wildcards could cause a segmentation fault.
* SET var_name = VALUES(col_name) could cause the server to exit. This syntax is now prohibited because in SET context there is no column name and the statement returns ER_BAD_FIELD_ERROR.
* The COM_CHANGE_USER command in the client/server protocol did not properly use the character set number in * Subqueries with OUTER JOIN could return incorrect results if the subquery referred to a column from another SELECT.
* Field_geom::reset() failed to reset its base Field_blob. The range optimizer used the uninitialized field during optimization and execution, causing the server to exit.
* mysql_install_db did not escape '_' in the host name for statements written to the grant tables.
* PARTITION BY KEY on a utf32 ENUM column raised a debugging assertion.
* The optimizer used loose index scan for some queries for which this access method is inapplicable.
* If a dump file contained a view with one character set and collation defined on a view with a different character set and collation, attempts to restore the dump file failed with an “illegal mix of collations” error.
* The REPLACE() function produced incorrect results when a user variable was supplied as an argument and the operation was performed on multiple rows.
* UNION ALL on BLOB columns could produce incorrect results.
* View access in low memory conditions could raise a debugging assertion.
* Setting max_connections to a value less than the current number of open connections caused the server to exit.
* Incorrect metadata could be produced for columns returned from some views.
* For debug builds, some queries with SELECT ... FROM DUAL nested subqueries raised an assertion.
* Adjusted MySQL configuration to account for change in Automake 1.12 that produced sql_yacc.hh rather than sql_yacc.h as expected by sql/Makefile.am.

# Functionality Added or Changed
* InnoDB: The innodb_print_all_deadlocks configuration option from MySQL 5.6 was backported to MySQL 5.5. This option records each deadlock condition in the MySQL error log, allowing easier troubleshooting if frequent deadlocks point to application coding issues.
* In RPM packages built for Unbreakable Linux Network, libmysqld.so now has a version number.
# Bugs Fixed
* InnoDB; Performance: Some data structures related to undo logging could be initialized unnecessarily during a query, although they were only needed under specific conditions.
* InnoDB; Performance: Optimized read operations for compressed tables by skipping redundant tests. The check for whether any related changes needed to be merged from the insert buffer was being called more often than necessary.
* InnoDB; Performance: Immediately after a table was created, queries against it would not use loose index scans. The issue went away following an ALTER TABLE on the table. The fix improves the accuracy of the index statistics gathered when the table is first created, and prevents the query plan from being changed by the ALTER TABLE statement.
* InnoDB; Partitioning: Previously, when attempting to optimize one or more partitions of a partitioned table that used a storage engine that does not support partition-level OPTIMIZE, such as InnoDB, MySQL reported Table does not support optimize, doing recreate + analyze instead, then re-created the entire table, but did not actually analyze it. Now in such cases, the warning message is, Table does not support optimize on partitions. All partitions will be rebuilt and analyzed. In addition, the entire table is analyzed after first being rebuilt.
* InnoDB: On systems that cannot handle unaligned memory access, depending on the stack frame alignment, a SIGBUS error could occur during startup. This issue was observed on Solaris 64-bit systems.
* InnoDB: The status variable Innodb_buffer_pool_read_ahead_evicted could show an inaccurate value, higher than expected, because some pages in the buffer pool were incorrectly considered as being brought in by read-ahead requests.
* InnoDB: Creating an index on a CHAR column could fail for a table with a character set with varying length, such as UTF-8, if the table was created with the ROW_FORMAT=REDUNDANT clause.
* InnoDB: The server could halt with an assertion error while creating an index: InnoDB: Assertion failure in thread thread_num in file row0merge.cc line 465 This issue affected tables with a combination of ROW_FORMAT=REDUNDANT off-page columns, and an index on a column prefix.
* InnoDB: If the server crashed at a precise moment during an ALTER TABLE operation that rebuilt the clustered index for an InnoDB table, the original table could be inaccessible afterward. An example of such an operation is ALTER TABLE ... ADD PRIMARY KEY The fix preserves the original table if the server halts during this operation. You might still need to rename the .ibd file manually to restore the original table contents: in MySQL 5.6 and higher, rename from #sql-ib$new_table_id.ibd to table_name.ibd within the database directory; prior to MySQL 5.6, the temporary file to rename is table_name#1 or #2.
* InnoDB: An error at the filesystem level, such as too many open files, could cause an unhandled error during an ALTER TABLE operation. The error could be accompanied by Valgrind warnings, and by this assertion message: Assertion `! is_set()' failed. mysqld got signal 6 ;
* InnoDB: A RENAME TABLE statement could stall for several minutes before timing out. This issue could occurred for a table using compression, with change buffering enabled.
* InnoDB: During shutdown, with the innodb_purge_threads configuration option set greater than 1, the server could halt prematurely with this error: mysqld got signal 11 A workaround was to increase innodb_log_file_size and set innodb_purge_threads=1. The fix was backported to MySQL 5.5 and 5.1, although those versions do not have the innodb_purge_threads configuration option so the error was unlikely to occur.
* InnoDB: If the value of innodb_force_recovery was less than 6, opening a corrupted table might loop forever if a corrupted page was read when calculating statistics for the table. Information about the corrupted page was written repeatedly to the error log, possibly causing a disk space issue. The fix causes the server to halt after a fixed number of failed attempts to read the page. To troubleshoot such a corruption issue, set innodb_force_recovery=6 and restart.
* InnoDB: The value of the innodb_version variable was not updated consistently for all server releases for the InnoDB Plugin in MySQL 5.1, and the integrated InnoDB component in MySQL 5.5, 5.6, and higher. Since InnoDB and MySQL Server development cycles are fully integrated and synchronized, now the value returned by the innodb_version variable is the same as for the version variable.
* Partitioning: Concurrent ALTER TABLE ... REBUILD PARTITION operations could interfere with one another, even when not running against the same table, because they both used global memory for storage. Now each partition rebuild operation stores intermediate data in memory that is local to that process.
* Partitioning: Inserting any number of rows into an ARCHIVE table that used more than 1000 partitions and then attempting to drop the table caused the MySQL Server to fail.
* Replication: After dropping a column from the slave's version of a table, then altering the same column of this table on the master (so that a type conversion would have been required had the column not been droppped on the slave), inserts into this table caused replication to fail.
* Replication: When a binary log is replayed on a server (for example, by executing a command like mysqlbinlog binlog.000001 | mysql), it sets a pseudo-slave mode on the client connection used, so that the server can read binlog and apply binary log events correctly. However, the pseudo-slave mode was not disabled after the binary log dump was read, which caused unexpected filtering rules to be applied to SQL statements subsequently executed on the same connection.
* Replication: When using statement-based replication, and where the master and the slave used table schemas having different AUTO_INCREMENT columns, inserts generating AUTO_INCREMENT values logged for a given table on the master could be applied to the wrong table on the slave.
* Replication: Repeated execution of CHANGE MASTER TO statements using invalid MASTER_LOG_POS values could lead to errors and possibly a crash on the slave. Now in such cases, the statement fails with a clear error message.
* Replication: If the disk becomes full while writing to the binary log, the server hangs until space is freed up manually. It was possible after this was done for the MySQL server to fail, due to an internal status value being set when not needed. Now in such cases, rather than trying to set this status, a warning is written in the error log instead.
* Microsoft Windows: Dynamic file names (with colons) are no longer allowed. Static file names using the Alternate Data Stream (ADS) NTFS functionality of Microsoft Windows may continue to be used.
* Joins of exactly 32 tables and containing a HAVING clause returned an empty result.
* A buffer-handling problem in yaSSL was fixed.
* A mysys library string-formatting routine could mishandle width specifiers.
* In certain cases, UpdateXML() could return NULL incorrectly.
* Metadata locking and table definition cache routines did not always check length of names passed to them.
* XA START had a race condition that could cause a server crash.
* Enabling the query cache during high client contention could cause the server to exit.
* There was a performance regression for queries using SELECT ... INTO user variables and a WHERE condition on one or more of the variables in the INTO list.
* The server sometimes failed to respect MAX_CONNECTIONS_PER_HOUR limits on user connections.
* Output generated with mysqldump --routines could produce syntax errors when reloaded.
* With the thread pool plugin installed, a workload consisting of concurrent KILL statements and ping queries caused the server to exit.
* CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had a corrupt key (.MYI) file. Now the server produces an error.
* Passing an unknown time zone specification to CONVERT_TZ() resulted in a memory leak.
* For dumps of the mysql database, mysqldump skipped the event table unless the --events option was given. To skip this table if that is desired, use the --ignore-table option instead
* For MEMORY tables with HASH indexes, DELETE sometimes failed to delete all applicable rows.
* The mysql client could mishandle the delimiter command if it occurred on a line during which mysql was looking for the end of a quoted string.
* mysqld_safe used the nonportable -e test construct.
* Configuring the server with performance_schema_events_waits_history_size=0 and performance_schema_events_waits_history_long_size=0 could cause a Performance Schema segmentation fault.
* DECIMAL multiplication operations could produce significant inaccuracy.
* For subqueries executing using a filesort, the optimizer could produce an incorrect result containing wrong rows.
* UNION type conversion could incorrectly turn unsigned values into signed values.
* During the startup process, mysqld could incorrectly remove the PID file of an already running mysqld.

# Bugs Fixed
* InnoDB; Performance: Some data structures related to undo logging could be initialized unnecessarily during a query, although they were only needed under specific conditions.
* InnoDB; Performance: Optimized read operations for compressed tables by skipping redundant tests. The check for whether any related changes needed to be merged from the insert buffer was being called more often than necessary.
* InnoDB; Performance: Immediately after a table was created, queries against it would not use loose index scans. The issue went away following an ALTER TABLE on the table. The fix improves the accuracy of the index statistics gathered when the table is first created, and prevents the query plan from being changed by the ALTER TABLE statement.
* InnoDB; Partitioning: Previously, when attempting to optimize one or more partitions of a partitioned table that used a storage engine that does not support partition-level OPTIMIZE, such as InnoDB, MySQL reported Table does not support optimize, doing recreate + analyze instead, then re-created the entire table, but did not actually analyze it. Now in such cases, the warning message is, Table does not support optimize on partitions. All partitions will be rebuilt and analyzed. In addition, the entire table is analyzed after first being rebuilt.
* InnoDB: The status variable Innodb_buffer_pool_read_ahead_evicted could show an inaccurate value, higher than expected, because some pages in the buffer pool were incorrectly considered as being brought in by read-ahead requests.
* InnoDB: Creating an index on a CHAR column could fail for a table with a character set with varying length, such as UTF-8, if the table was created with the ROW_FORMAT=REDUNDANT clause.
* InnoDB: If the server crashed at a precise moment during an ALTER TABLE operation that rebuilt the clustered index for an InnoDB table, the original table could be inaccessible afterward. An example of such an operation is ALTER TABLE ... ADD PRIMARY KEY The fix preserves the original table if the server halts during this operation. You might still need to rename the .ibd file manually to restore the original table contents: in MySQL 5.6 and higher, rename from #sql-ib$new_table_id.ibd to table_name.ibd within the database directory; prior to MySQL 5.6, the temporary file to rename is table_name#1 or #2.
* InnoDB: An error at the filesystem level, such as too many open files, could cause an unhandled error during an ALTER TABLE operation. The error could be accompanied by Valgrind warnings, and by this assertion message: Assertion `! is_set()' failed. mysqld got signal 6 ;
* InnoDB: During shutdown, with the innodb_purge_threads configuration option set greater than 1, the server could halt prematurely with this error: mysqld got signal 11 A workaround was to increase innodb_log_file_size and set innodb_purge_threads=1. The fix was backported to MySQL 5.5 and 5.1, although those versions do not have the innodb_purge_threads configuration option so the error was unlikely to occur.
* InnoDB: The value of the innodb_version variable was not updated consistently for all server releases for the InnoDB Plugin in MySQL 5.1, and the integrated InnoDB component in MySQL 5.5, 5.6, and higher. Since InnoDB and MySQL Server development cycles are fully integrated and synchronized, now the value returned by the innodb_version variable is the same as for the version variable.
* Partitioning: When used with a table having multiple columns in its primary key, but partitioned by KEY using a column that was not part of the primary key as the partitioning column, a query using an aggregate function and DISTINCT such as SELECT SUM(DISTINCT pk_column_1) FROM table WHERE pk_column_2 = constant was not handled correctly.
* Replication: Repeated execution of CHANGE MASTER TO statements using invalid MASTER_LOG_POS values could lead to errors and possibly a crash on the slave. Now in such cases, the statement fails with a clear error message.
* Replication: If the disk becomes full while writing to the binary log, the server hangs until space is freed up manually. It was possible after this was done for the MySQL server to fail, due to an internal status value being set when not needed. Now in such cases, rather than trying to set this status, a warning is written in the error log instead.
* Microsoft Windows: Dynamic file names (with colons) are no longer allowed. Static file names using the Alternate Data Stream (ADS) NTFS functionality of Microsoft Windows may continue to be used.
* Directory name manipulation could result in stack overflow on Mac OS X and Windows.
* A buffer-handling problem in yaSSL was fixed.
* It was possible in theory for UpdateXML() to return NULL incorrectly.
* Metadata locking and table definition cache routines did not always check length of names passed to them.
* Enabling the query cache during high client contention could cause the server to exit.
* The server sometimes failed to respect MAX_CONNECTIONS_PER_HOUR limits on user connections.
* Passing an unknown time zone specification to CONVERT_TZ() resulted in a memory leak.
* For MEMORY tables with HASH indexes, DELETE sometimes failed to delete all applicable rows.
* mysqld_safe used the nonportable -e test construct.
* UNION type conversion could incorrectly turn unsigned values into signed values.
* During the startup process, mysqld could incorrectly remove the PID file of an already running mysqld.

# Functionality Added or Changed
* The SHOW AUTHORS and SHOW CONTRIBUTORS statements are now deprecated in MySQL 5.5 and have been removed in MySQL 5.6.
# Bugs Fixed
* Performance: InnoDB: The timing values for low-level InnoDB read operations were adjusted for better performance with fast storage devices, such as SSD. This enhancement primarily affects read operations for BLOB columns in compressed tables.
* Important Change: InnoDB: A DML statement using the index merge access method could lock many rows from the table, even when those rows were not part of the final result set. This fix reduces the excessive locking by releasing the locks of unmatched rows. This optimization affects only transactions with isolation level equal to or less strict than READ COMMITTED; it does not apply to transactions using REPEATABLE READ or SERIALIZABLE isolation level.
* InnoDB: An online DDL operation for an InnoDB table incorrectly reported an empty value ('') instead of the correct key value when it reported a duplicate key error for a unique index using an index prefix.
* InnoDB: If a CREATE TABLE statement failed due to a disk full error, some memory allocated during the operation was not freed properly.
* InnoDB: With the innodb_file_per_table setting enabled, a DROP TABLE operation could cause a crash, due to a race condition that depended on the timing of pending I/O requests.
* InnoDB: If the server crashed at the specific point when a change buffer entry was being merged into a buffer pool page, the transaction log and the change buffer were left in an inconsistent state. After a restart, MySQL could crash after reading the corresponding secondary index page. The problem was more likely to occur in MySQL 5.5 or later, where the original insert buffering mechanism was generalized to cover other operations.
* InnoDB: Inserting data of varying record lengths into an InnoDB table that used compression could cause the server to halt with an error.
* InnoDB: If a table was defined with an index key length very close to the upper length limit of 3072, a query against that table could cause a serious error.
* InnoDB: When an auto-increment column used a FLOAT or DOUBLE data type, if the auto-increment value became very large (larger than the maximum unsigned long long value), subsequent inserts could fail or cause the server to halt.
* InnoDB: If a transaction was started with a consistent snapshot, then new indexes were added to the table while the transaction was in progress, a subsequent UPDATE statement could incorrectly encounter the error:
- HA_ERR_TABLE_DEF_CHANGED: insufficient history for index
- This issue could cause an assertion error in debug builds.
* InnoDB: The error message was improved for the case where an UPDATE failed because the row included several BLOB values greater than 768 bytes each, causing the size of a row to exceed half the page size. The old message, was misleading; it suggested using BLOBs, when the 768-byte prefix for each BLOB column was the cause of the limit error:
- Error Code 1118: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. You have to change some columns to TEXT or BLOBs
- A workaround for the problem was to create the table with the ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED clause, which is now suggested in the message.
* InnoDB: In rare circumstances, MySQL could apply InnoDB undo records out of order during a ROLLBACK of an operation that modified a BLOB column. This issue could cause an assertion error in debug builds:
- !bpage->file_page_was_freed
* Replication: Updates writing user variables whose values were never set on a slave while using --replicate-ignore-table could cause the slave to fail.
* Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on the slave.
* Replication: Following an insert into a nontransactional table that failed due to insufficient disk space, the server did not properly clean up all pending events, leading to an assert or possibly to other errors.
* Very long database names in queries could cause the server to exit.
* Within a stored procedure, executing a multiple-table DELETE statement that used a very long table alias could cause the server to exit.
* Very long table aliases in queries could cause the server to exit.
* Attempting to create an auto-increment column in an InnoDB table with a NULL type attribute could cause a serious error.
* A DELETE statement for an InnoDB table could write incorrect transaction metadata into a record, causing the server to halt with an error. To work around this issue, reduce the specified length of the primary key to less than 1K bytes.
* Repeated execution of a query containing a subquery that used MAX() could result in increasing memory consumption.
* USE dbname could fail with Unknown database when dbname contained multiple backtick (`) characters.
* The configure.pl script that converts GNU configure options to CMake equivalents generated erroneous output for the --with-client-ldflags and --with-mysqld-ldflags options. It now ignores those options.
* SHOW PROFILE could be used to cause excessive server memory consumption.
* The thread cache implementation worked in LIFO rather than FIFO fashion and could result in a thread being denied service (although this was a remote possibility).
* Within a stored program, memory allocated to hold condition information was not released until program exit, leading to excessive memory use.
* Improper memory cleanup could cause the server to exit.
* Granting or revoking the PROXY privilege caused the server to exit if the server was started with --skip-name-resolve.
* CREATE USER and DROP USER could fail to flush the privileges, requiring FLUSH PRIVILEGES to be used explicitly.
* Access to INFORMATION_SCHEMA tables through a view could leak memory.
* A memory leak could occur for queries containing a subquery that used GROUP BY on an outer column.
* On Microsoft Windows with CMake 2.6, the build process would not stop if the create_initial_db step failed.
* The test in mysqld_safe for the presence of the --plugin_dir option and assignment of a default value to it were performed before the actual argument parsing took place.
* CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had a corrupt key (.MYI) file. Now the server produces an error.
* Improper memory cleanup could cause the server to exit.
* A memory leak occurred due to failure to clean up after QUICK_INDEX_MERGE_SELECT/Unique.
* The number of connection errors from a given host as counted by the server was periodically reset, with the result that max_connect_errors was never reached and invalid hosts were never blocked from trying to connect.
* During optimization, ZEROFILL values may be converted to string constants. However, CASE expressions did not handle switching data types after the planning stage, leading to CASE finding a null pointer instead of its argument.
* In debug builds, an InnoDB assertion was overly aggressive about prohibiting an open range.
* On Windows, the Perl version of mysql_install_db created system tables in the mysql database that were not populated properly.
* mysqld_safe ignored the value of the UMASK environment variable, leading to behavior different from mysqld with respect to the access mode of created files. Now mysqld_safe (and mysqld_multi) attempt to approximate the same behavior as mysqld.
* LAST_INSERT_ID(expr) did not work for expr values greater than the largest signed BIGINT value.

# Functionality Added or Changed
* The internal interface of the Thread Pool plugin has changed. Old versions of the plugin will work with current versions of the server, but versions of the server older than 5.5.28 will not work with current versions of the plugin.
# Bugs Fixed
* InnoDB: Certain information_schema tables originally introduced in MySQL 5.6 are now also available in MySQL 5.5 and MySQL 5.1: INNODB_BUFFER_PAGE, INNODB_BUFFER_PAGE_LRU, and INNODB_BUFFER_POOL_STATS.
* InnoDB: When a SELECT ... FOR UPDATE, UPDATE, or other SQL statement scanned rows in an InnoDB table using a < or <= operator in a WHERE clause, the next row after the affected range could also be locked. This issue could cause a lock wait timeout for a row that was not expected to be locked. The issue occurred under various isolation levels, such as READ COMMITTED and REPEATABLE READ.
* Partitioning: For tables using PARTITION BY HASH or PARTITION BY KEY, when the partition pruning mechanism encountered a multi-range list or inequality using a column from the partitioning key, it continued with the next partitioning column and tried to use it for pruning, even if the previous column could not be used. This caused partitions which possibly matched one or more of the previous partitioning columns to be pruned away, leaving partitions that matched only the last column of the partitioning key.
- This issue was triggered when both of the following conditions were met:
> The columns making up the table's partitioning key were used in the same order as in the partitioning key definition by a SELECT statement's WHERE clause as in the column definitions;
> The WHERE condition used with the last column of the partitioning key was satisfied only by a single value, while the condition testing some previous column from the partitioning key was satisfied by a range of values.
An example of a statement creating a partitioned table and a query against this for which the issue described above occurred is shown here:
CREATE TABLE t1 (
c1 INT,
c2 INT,
PRIMARY KEY(c2, c1)
) PARTITION BY KEY() # Use primary key as partitioning key
PARTITIONS 2;
SELECT * FROM t1 WHERE c2 = 2 AND c1 <> 2;
This issue is resolved by ensuring that partition pruning skips any remaining partitioning key columns once a partition key column that cannot be used in pruning is encountered.
* Partitioning: The buffer for the row currently read from each partition used for sorted reads was allocated on open and freed only when the partitioning handler was closed or destroyed. For SELECT statements on tables with many partitions and large rows, this could cause the server to use excessive amounts of memory. This issue has been addressed by allocating buffers for reads from partitioned tables only when they are needed and freeing them immediately once they are no longer needed. As part of this fix, memory is now allocated for reading from rows only in partitions that have not been pruned.
* Replication: On 64-bit Windows platforms, values greater than 4G for the max_binlog_cache_size and max_binlog_stmt_cache_size system variables were truncated to 4G. This caused LOAD DATA INFILE to fail when trying to load a file larger than 4G in size, even when max_binlog_cache_size was set to a value greater than this.
* Replication: In master-master replication with --log-slave-updates enabled, setting a user variable and then performing inserts using this variable caused the Exec_master_log_position column in the output of SHOW SLAVE STATUS not to be updated.
* The RPM spec file now also runs the test suite on the new binaries, before packaging them.
* The libmysqlclient_r client library exported symbols from yaSSL that conflict with OpenSSL. If a program linked against that library and libcurl, it could crash with a segmentation fault.
* The argument for LIMIT must be an integer, but if the argument was given by a placeholder in a prepared statement, the server did not reject noninteger values such as '5'.
* The Thread Pool plugin did not respect the wait_timeout timeout for client sessions.
* CHECK TABLE and REPAIR TABLE could crash if a key definition differed in the .frm and .MYI files of a MyISAM table. Now the server produces an error.
* A query for a FEDERATED table could return incorrect results when the underlying table had a compound index on two columns and the query included an AND condition on the columns.
* mysqlhotcopy failed for databases containing views.
* The argument to the --ssl-key option was not verified to exist and be a valid key. The resulting connection used SSL, but the key was not used.
* Adding a LIMIT clause to a query containing GROUP BY and ORDER BY could cause the optimizer to choose an incorrect index for processing the query, and return more rows than required.
* mysqlbinlog did not accept input on the standard input when the standard input was a pipe.

# Bugs Fixed
* InnoDB: Certain information_schema tables originally introduced in MySQL 5.6 are now also available in MySQL 5.5 and MySQL 5.1: INNODB_BUFFER_PAGE, INNODB_BUFFER_PAGE_LRU, and INNODB_BUFFER_POOL_STATS.
* InnoDB: When a SELECT ... FOR UPDATE, UPDATE, or other SQL statement scanned rows in an InnoDB table using a < or <= operator in a WHERE clause, the next row after the affected range could also be locked. This issue could cause a lock wait timeout for a row that was not expected to be locked. The issue occurred under various isolation levels, such as READ COMMITTED and REPEATABLE READ.
* Partitioning: The buffer for the row currently read from each partition used for sorted reads was allocated on open and freed only when the partitioning handler was closed or destroyed. For SELECT statements on tables with many partitions and large rows, this could cause the server to use excessive amounts of memory. This issue has been addressed by allocating buffers for reads from partitioned tables only when they are needed and freeing them immediately once they are no longer needed. As part of this fix, memory is now allocated for reading from rows only in partitions that have not been pruned.
* Replication: In master-master replication with --log-slave-updates enabled, setting a user variable and then performing inserts using this variable caused the Exec_master_log_position column in the output of SHOW SLAVE STATUS not to be updated.
* Small sort_buffer_size values could result in a server crash.
* The libmysqlclient_r client library exported symbols from yaSSL that conflict with OpenSSL. If a program linked against that library and libcurl, it could crash with a segmentation fault.
* The argument for LIMIT must be an integer, but if the argument was given by a placeholder in a prepared statement, the server did not reject noninteger values such as '5'.
* Access to INFORMATION_SCHEMA tables through a view could leak memory.
* A query for a FEDERATED table could return incorrect results when the underlying table had a compound index on two columns and the query included an AND condition on the columns.
* The argument to the --ssl-key option was not verified to exist and be a valid key. The resulting connection used SSL, but the key was not used.
* In debug builds, an InnoDB assertion was overly aggressive about prohibiting an open range.
* Adding a LIMIT clause to a query containing GROUP BY and ORDER BY could cause the optimizer to choose an incorrect index for processing the query, and return more rows than required.
* mysqlbinlog did not accept input on the standard input when the standard input was a pipe.

# Functionality Added or Changed
* Important Change: The YEAR(2) data type is now deprecated because it is problematic. Support for YEAR(2) will be removed in a future release of MySQL.

* Functionality Added or Changed
- Important Change: The YEAR(2) data type is now deprecated because it is problematic. Support for YEAR(2) will be removed in a future release of MySQL.
* Bugs Fixed
- InnoDB: A race condition could cause assertion errors during a DROP TABLE statement for an InnoDB table. Some internal InnoDB functions did not correctly determine if a tablespace was missing; other functions did not handle the error code correctly if a tablespace was missing.
- InnoDB: If a row was deleted from an InnoDB table, then another row was re-inserted with the same primary key value, an attempt by a concurrent transaction to lock the row could succeed when it should have waited. This issue occurred if the locking select used a WHERE clause that performed an index scan using a secondary index.
- InnoDB: An assertion could be raised if an InnoDB table was moved to a different database using ALTER TABLE ... RENAME while the database was being dropped by DROP DATABASE.
- InnoDB: Using the KILL statement to terminate a query could cause an unnecessary message in the error log: [ERROR] Got error -1 when reading table table_name
- InnoDB: For an InnoDB table with a trigger, under the setting innodb_autoinc_lock_mode=1, sometimes auto-increment values could be interleaved when inserting into the table from two sessions concurrently. The sequence of auto-increment values could vary depending on timing, leading to data inconsistency in systems using replication.
- Replication: An event whose length exceeded the size of the master dump thread's max_allowed_packet caused replication to fail. This could occur when updating many large rows and using row-based replication. As part of this fix, a new server option --slave-max-allowed-packet is added, which permits max_allowed_packet to be exceeded by the slave SQL and I/O threads. Now the size of a packet transmitted from the master to the slave is checked only against this value (available as the value of the slave_max_allowed_packet server system variable), and not against the value of max_allowed_packet.
- Replication: Statements such as UPDATE ... WHERE primary_key_column = constant LIMIT 1 are flagged as unsafe for statement-based logging, despite the fact that such statements are actually safe. In cases where a great many such statements were run, this could lead to disk space becoming exhausted do to the number of such false warnings being logged. To prevent this from happening, a warning suppression mechanism is introduced. This warning suppression acts as follows: Whenever the 50 most recent ER_BINLOG_UNSAFE_STATEMENT warnings have been generated more than 50 times in any 50-second period, warning suppression is enabled. When activated, this causes such warnings not to be written to the error log; instead, for each 50 warnings of this type, a note is written to the error log stating The last warning was repeated N times in last S seconds. This continues as long as the 50 most recent such warnings were issued in 50 seconds or less; once the number of warnings has decreased below this threshold, the warnings are once again logged normally. The fix for this issue does not affect how these warnings are reported to MySQL clients; a warning is still sent to the client for each statement that generates the warning. This fix also does not make any changes in how the safety of any statement for statement-based logging is determined.
- Replication: After upgrading a replication slave to MySQL 5.5.18 or later, enabling the query cache eventually caused the slave to fail.
- The server did not build with gcc 4.7.
- Certain arguments to RPAD() could lead to “uninitialized variable” warnings.
- The presence of a file named .empty in the test database prevented that database from being dropped.
- For some subqueries that should be executed using a range scan on a non-primary index and required use of filesort, only the first execution of the subquery was done as a range scan. All following executions were done as full table scans, resulting in poor performance.
- The number of connection errors from a given host as counted by the server was periodically reset, with the result that max_connect_errors was never reached and invalid hosts were never blocked from trying to connect.
- File access by the ARCHIVE storage engine was not instrumented and thus not shown in Performance Schema tables.
- mysqlbinlog exited with no error code if file write errors occurred.
- Using CONCAT() to construct a pattern for a LIKE pattern match could result in memory corrupting and match failure.
- yaSSL rejected valid SSL certificates that OpenSSL accepts.
- Sessions could end up deadlocked when executing a combination of SELECT, DROP TABLE, KILL, and SHOW ENGINE INNODB STATUS.
- mysqldump could dump views and the tables on which they depend in such an order that errors occurred when the dump file was reloaded.

# Bugs Fixed
* A regression bug in the optimizer could cause excessive disk usage for UPDATE statements.

# Bugs Fixed
* Performance: InnoDB: Improved the algorithm related to adaptive flushing. This fix increases the rate of flushing in cases where compression is used and the data set is larger than the buffer pool, leading to eviction.
* InnoDB: In a transaction using the REPEATABLE READ isolation level, an UPDATE or DELETE statement for an InnoDB table could sometimes overlook rows recently committed by other transactions. As explained in Section 14.3.9.2, “Consistent Nonlocking Reads”, DML statements within a REPEATABLE READ transaction apply to rows committed by other transactions, even if a query could not see those rows.
* InnoDB: The Innodb_buffer_pool_pages_flushed status variable was incorrectly set to twice the value it should be. Its value should never exceed the value of Innodb_pages_written.
* InnoDB: The error handling and message was improved for attempting to create a foreign key with a column referencing itself. The message suggested a potential problem with the data dictionary, when no such problem existed.
* InnoDB: The CHECK TABLE statement could fail for a large InnoDB table due to a timeout value of 2 hours. For typical storage devices, the issue could occur for tables that exceeded approximately 200 or 350 GB, depending on I/O speed. The fix relaxes the locking performed on the table being checked, which makes the timeout less likely. It also makes InnoDB recognize the syntax CHECK TABLE QUICK, which avoids the possibility of the timeout entirely.
* Replication: It was theoretically possible for concurrent execution of more than one instance of SHOW BINLOG EVENTS to crash the MySQL Server.
* Replication: Statements using AUTO_INCREMENT, LAST_INSERT_ID(), RAND(), or user variables could be applied in the wrong context on the slave when using statement-based replication and replication filtering server options (see Section 16.2.3, “How Servers Evaluate Replication Filtering Rules”).
* Replication: An INSERT into a table that has a composite primary key that includes an AUTO_INCREMENT column that is not the first column of this composite key is not safe for statement-based binary logging or replication. Such statements are now marked as unsafe and fail with an error when using the STATEMENT binary logging format. For more information, see Section 16.1.2.3, “Determination of Safe and Unsafe Statements in Binary Logging”, as well as Section 16.4.1.1, “Replication and AUTO_INCREMENT”.
- Note : Tables using the InnoDB storage engine are not affected by this issue, since InnoDB does not allow the creation of a composite key that includes an AUTO_INCREMENT column, where this column is not the first column in the key.
* SHOW TABLES was very slow unless the required information was already in the disk cache.

# Bugs Fixed
* Security Fix: Bug #64884 was fixed.
* InnoDB: Replication: When binary log statements were replayed on the slave, the Com_insert, Com_update, and Com_delete counters were incremented by BEGIN statements initiating transactions affecting InnoDB tables but not by COMMIT statements ending such transactions. This affected these statements whether they were replicated or they were run using mysqlbinlog.
* If the --bind-address option was given a host name value and the host name resolved to more than one IP address, the server failed to start. For example, with --bind-address=localhost, if localhost resolved to both 127.0.0.1 and ::1, startup failed. Now the server prefers the IPv4 address in such cases.
* mysql_store_result() and mysql_use_result() are not for use with prepared statements and are not intended to be called following mysql_stmt_execute(), but failed to return an error when invoked that way in libmysqld.
* On Windows, mysqlslap crashed for attempts to connect using shared memory.