MySQL 5.6.36

# Functionality Added or Changed
* Incompatible Change: The AES_ENCRYPT() and AES_DECRYPT() functions now permit control of the block encryption mode and take an optional initialization vector argument:
- The new block_encryption_mode system variable controls the mode for block-based encryption algorithms. Its default value is aes-128-ecb, which signifies encryption using a key length of 128 bits and ECB mode.
- An optional init_vector argument provides an initialization vector for encryption modes that require it:
> AES_ENCRYPT(str,key_str[,init_vector])
> AES_DECRYPT(crypt_str,key_str[,init_vector])
- A random string of bytes to use for the initialization vector can be produced by calling the new RANDOM_BYTES() function.
* Incompatible Change: The deprecated ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE SQL modes now do nothing. Instead, their previous effects are included in the effects of strict SQL mode (STRICT_ALL_TABLES or STRICT_TRANS_TABLES). In other words, strict mode now means the same thing as the previous meaning of strict mode plus the ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE modes. This change reduces the number of SQL modes with an effect dependent on strict mode and makes them part of strict mode itself.
* InnoDB: MySQL now supports rebuilding regular and partitioned InnoDB tables using online DDL (ALGORITHM=INPLACE) for the following operations:
- OPTIMIZE TABLE
- ALTER TABLE ... FORCE
- ALTER TABLE ... ENGINE=INNODB (when run on an InnoDB table)
* On Solaris, mysql_config --libs now includes -R/path/to/library so that libraries can be found at runtime.
* mysql_install_db provides a more informative diagnostic message when required Perl modules are missing.
* The IGNORE clause for ALTER TABLE is now deprecated and will be removed in a future version of MySQL. ALTER IGNORE TABLE causes problems for replication, prevents online ALTER TABLE for unique index creation, and causes problems with foreign keys (rows removed in the parent table).
# Bugs Fixed
* Incompatible Change: Old clients (older than MySQL 5.5.7) failed to parse authentication data correctly if the server was started with the --default-authentication-plugin=sha256_password option.
* Important Change; InnoDB; Partitioning: The FLUSH TABLES statement's FOR EXPORT option is now supported for partitioned InnoDB tables.
* InnoDB: Running a SELECT on a partitioned table caused a memory access violation in memcpy().
* InnoDB: An invalid memmove in fts_query_fetch_document would cause a serious error.
* InnoDB: For full-text queries, a failure to check that num_token is less than max_proximity_item could result in an assertion.
* InnoDB: innodb_ft_result_cache_limit now has a hardcoded maximum value of 4294967295 bytes or (2**32 -1). The maximum value was previously defined as the maximum value of ulong.
* InnoDB: InnoDB would fail to restore a corrupt first page of a system tablespace data file from the doublewrite buffer, resulting in a startup failure.
* InnoDB: An UPDATE resulted in a memory access error in lock_rec_other_trx_holds_expl. The transaction list (trx_sys->rw_trx_list) was traversed without acquiring the transaction subsystem mutex (trx_sys->mutex).
* InnoDB: A regression introduced would result in a performance degradation when a compressed table does not fit into memory.
* InnoDB: The maximum value for innodb_thread_sleep_delay is now 1000000 microseconds. The previous maximum value (4294967295 microseconds on 32-bit and 18446744073709551615 microseconds on 64-bit) was unnecessarily large. Because the maximum value of innodb_thread_sleep_delay is limited by the value set for innodb_adaptive_max_sleep_delay (when set to a non-zero value), the maximum value for innodb_thread_sleep_delay is now the same as the maximum value for innodb_adaptive_max_sleep_delay.
* InnoDB: A full-text tokenizer thread would terminate with an incorrect error message.
* InnoDB: Attempting to uninstall the InnoDB memcached plugin while the InnoDB memcached plugin is still initializing would kill the InnoDB memcached daemon thread. Uninstall should wait until initialization is complete.
* InnoDB: In debug builds, creating a unique index on a binary column, with input data containing duplicate keys, would cause an assertion.
* InnoDB: The srv_monitor_thread would crash in the lock_print_info_summary() function due to a race condition between the srv_monitor_thread and purge coordinator thread.
* InnoDB: Attempting to add an invalid foreign key when foreign key checking is disabled (foreign_key_checks=0) would cause a serious error.
* InnoDB: For debug builds, the table rebuilding variant of online ALTER TABLE, when run on tables with BLOB columns, would cause an assertion in the row_log_table_apply_update function. For normal builds, a DB_PRODUCTION error would be returned.
* InnoDB: When creating a table there are a minimum of three separate inserts on the mysql.innodb_index_stats table. To improve CREATE TABLE performance, there is now a single COMMIT operation instead of one for each insert.
* InnoDB: The server would halt with an assertion in lock_rec_has_to_wait_in_queue(lock) due to a locking-related issue and a transaction being prematurely removed from trx_sys->rw_trx_set.
* InnoDB: Server shutdown would result in a hang with the following message written to the error log: “[NOTE] InnoDB: Waiting for purge thread to be suspended.”
* InnoDB: InnoDB would fail to start when innodb_data_file_path specified the data file size in kilobytes by appending K to the size value.
* InnoDB: An insert buffer merge would cause an assertion error due to incorrectly handled ownership information for externally stored BLOBs.
* InnoDB: Assertion failure in thread thread_num in file ibuf0ibuf.cc line 4080
* InnoDB: Failing assertion: rec_get_deleted_flag(rec, page_is_comp(page))
* InnoDB: Decreasing the auto_increment_increment value would have no affect on the next auto-increment value.
* Partitioning: When the index_merge_intersection flag (enabled by default) or the index_merge_union flag was enabled by the setting of the optimizer_switch system variable, queries returned incorrect results when executed against partitoned tables that used the MyISAM storage engine, as well as partitioned InnoDB tables that lacked a primary key.
* Replication: The MASTER_SSL_CRL and MASTER_SSL_CRLPATH options are not available when using yaSSL; MySQL Replication now sets these to NULL automatically whenever yaSSL is enabled.
* Replication: Setting --slave-parallel-workers to 1 or greater and starting the slave caused the slave SQL thread to use but not release memory until the slave was restarted with STOP SLAVE and START SLAVE.
* Replication: When a slave was configured with replication filters and --log-warnings=2, every statement which was filtered caused an entry to be written in the error log. For busy servers which generated many statements to be filtered, the result was that the error log could quickly grow to many gigabytes in size. Now a throttle is used for such errors, so that an error message is printed only once in a given interval, saying that this particular error occurred a specific number of times during that interval.
* Replication: SHOW SLAVE STATUS used incorrect values when reporting MASTER_SSL_CRL and MASTER_SSL_CRLPATH.
* Replication: Binary log events could be sent to slaves before they were flushed to disk on the master, even when sync_binlog was set to 1. This could lead to either of those of the following two issues when the master was restarted following a crash of the operating system:
- Replication cannot continue because one or more slaves are requesting replicate events that do not exist on the master.
- Data exists on one or more slaves, but not on the master.
* Replication: When running the slave with --slave-parallel-workers at 1 or greater, setting --slave-skip-errors=all caused the error log to be filled with with instances of the warning Slave SQL: Could not execute Query event. Detailed error: ;, Error_code: 0.
* Replication: A number of possible state messages used as values for the PROCESSLIST_STATE column of the Performance Schema threads table were longer than the width of the column (64 characters).
* Replication: The server did not handle correctly the insertion of a row larger than 4 GB when using row-based replication.
* Replication: When using row-based replication, an additional auto-increment column on the slave version of a table was not updated correctly; a zero was inserted instead.
* Replication: Statements involving the Performance Schema tables should not be written to the binary log, because the content of these tables is applicable only to a given MySQL Server instance, and may differ greatly between different servers in a replication topology. The database administrator should be able to configure (INSERT, UPDATE, or DELETE) or flush (TRUNCATE TABLE) performance schema tables on a single server without affecting others. However, when replicating from a MySQL 5.5 master to a MySQL 5.5 or later slave, warnings about unsafe statements updating Performance Schema tables were elevated to errors. For MySQL 5.6 and later slaves, this prevented the simultaneous use of performance_schema and GTIDs
* Replication: Modifying large amounts of data within a transaction can cause the creation of temporary files. Such files are created when the size of the data modified exceeds the size of the binary log cache (max_binlog_cache_size). Previously, such files persisted until the client connection was closed, which could allow them to grow until they exhausted all available disk space in tmpdir. To prevent this from occurring, the size of a temporary file created in this way in a given transaction is now reset to 0 when the transaction is committed or rolled back.
* Replication: The server checks to determine whether semisynchronous replication has been enabled without a lock, and if this is the case, it takes the lock and checks again. If semisynchronous replication was disabled after the first but prior to the second one, this could cause the server to fail.
* Replication: Semisynchronous replication became very slow if there were many dump threads (such as from mysqlbinlog or slave I/O connections) working at the same time. It was also found that semisynchronous master plugin functions were called even when the dump connections did not support semisynchronous replication, which led to locking of the plugin lock as well as wasting time on necessary code.
* After this fix, non-semisynchronous dump threads no longer call semisynchronous master functions to observe binary events.
* mysql_install_db could hang while reading /dev/random to generate a random root password.
* Compilation failed if MySQL was configured with CFLAGS set to include a -Werror option with an argument.
* A shared libmysqld embedded server library was not built on Linux.
* While printing the server version, the mysql client did not check for buffer overflow in a string variable.
* Building MySQL from source on Windows using Visual Studio 2008 would fail with an identifier not found error due to a regression
* On Microsoft Windows, the rw-lock backup implementation for the my_atomic_* functions was always used. Now, the native Microsoft Windows implementation is used, where available.
* When tables are reopened from the table cache and the current thread is not instrumented for the Performance Schema, a table handle was unnecessarily instrumented.
* The audit log plugin could cause a server exit during log file rotation operations when there were many operations happening for multiple connections.
* The SUM_SORT_MERGE_PASSES column value in the Performance Schema events_statements_summary_by_digest table was calculated incorrectly.
* If the Performance Schema events_statements_summary_by_digest table was full when a statement with a new digest was found, the Performance_schema_digest_lost status variable was not incremented.
* The optimizer could push down a condition when the index did not have the key part present in the condition.
* Contraction information in a collation could be mishandled, resulting in incorrect decisions about whether a character is part of a contraction, and miscalculation of contraction weights.
* DROP TRIGGER succeeded even with the read_only system variable enabled.
* If used to process a prepared CALL statement for a stored procedure with OUT or INOUT parameters, mysql_stmt_store_result() did not properly set the flags required to retrieve all the result sets.
* When run by root, mysqld --help --verbose exited with a nonzero error code after displaying the help message.
* MySQL client programs from a Community Edition distribution could not connect using SSL to a MySQL server from an Enterprise Edition. This was due to a difference in certificate handling by yaSSL and OpenSSL (used for Community and Enterprise, respectively). OpenSSL expected a blank certificate to be sent when not all of the --ssl-ca, --ssl-cert, and --ssl-key options were specified, and yaSSL did not do so. To resolve this, yaSSL has been modified to send a blank certificate when an option is missing.
* The mysqladmin, mysqlbinlog, mysqlcheck, mysqldump, mysqlimport, mysqlslap, and mysqlshow programs now support a --secure-auth option that prevents sending passwords to the server in old (pre-4.1) format. This option is enabled by default; use --skip-secure-auth to disable it.
* A deadlock error occurring during subquery execution could cause an assertion to be raised.
* The Performance Schema stage/sql/Waiting to get readlock instrument is no longer used and has been removed.
* A query that creates a temporary table to find distinct values and has a constant value in the projected list could produce incorrect results.
* Messages written by the server to the error log for LDML collation definition problems were missing the collation name.
* mysqlcheck did not correctly handle table names containing dots.
* Aggregating the results of a subquery in the FROM clause could produce incorrect results.
* For system variables that take a string value, SET statements permitted an unquoted value, but values that contained dots were parsed incorrectly and only part of the value was assigned. For example, SET GLOBAL slow_query_log_file = my_slow.log assigned the value my_slow. Now such values must be quoted or an error occurs.
* A temporal literal string without delimiters and more than 14 digits was validated as a TIMESTAMP/DATETIME value with a two-digit precision fractional seconds part. But fractional seconds should always be separated from other parts of a time by a decimal point.
* The msql2mysql, mysql_convert_table_format, mysql_find_rows, mysql_fix_extensions, mysql_setpermission, and mysqlaccess utilities are now deprecated and will be removed in MySQL 5.7.

# Functionality Added or Changed
* On Solaris, mysql_config --libs now includes -R/path/to/library so that libraries can be found at runtime.
# Bugs Fixed
* InnoDB: A regression introduced by Bug #14329288 would result in a performance degradation when a compressed table does not fit into memory.
* InnoDB: The maximum value for innodb_thread_sleep_delay is now 1000000 microseconds. The previous maximum value (4294967295 microseconds on 32-bit and 18446744073709551615 microseconds on 64-bit) was unnecessarily large. Because the maximum value of innodb_thread_sleep_delay is limited by the value set for innodb_adaptive_max_sleep_delay (when set to a non-zero value), the maximum value for innodb_thread_sleep_delay is now the same as the maximum value for innodb_adaptive_max_sleep_delay.
* InnoDB: In debug builds, creating a unique index on a binary column, with input data containing duplicate keys, would cause an assertion.
* InnoDB: InnoDB would fail to start when innodb_data_file_path specified the data file size in kilobytes by appending K to the size value.
* InnoDB: An insert buffer merge would cause an assertion error due to incorrectly handled ownership information for externally stored BLOBs.
* InnoDB: Assertion failure in thread thread_num in file ibuf0ibuf.cc line 4080
* InnoDB: Failing assertion: rec_get_deleted_flag(rec, page_is_comp(page))
* InnoDB: Decreasing the auto_increment_increment value would have no affect on the next auto-increment value.
* Replication: The server did not handle correctly the insertion of a row larger than 4 GB when using row-based replication.
* Replication: When using row-based replication, an additional auto-increment column on the slave version of a table was not updated correctly; a zero was inserted instead.
* Replication: Statements involving the Performance Schema tables should not be written to the binary log, because the content of these tables is applicable only to a given MySQL Server instance, and may differ greatly between different servers in a replication topology. The database administrator should be able to configure (INSERT, UPDATE, or DELETE) or flush (TRUNCATE TABLE) performance schema tables on a single server without affecting others. However, when replicating from a MySQL 5.5 master to a MySQL 5.5 or later slave, warnings about unsafe statements updating Performance Schema tables were elevated to errors. For MySQL 5.6 and later slaves, this prevented the simultaneous use of performance_schema and GTIDs (see Replication with Global Transaction Identifiers, in the MySQL 5.6 Manual).
* Compilation failed if MySQL was configured with CFLAGS set to include a -Werror option with an argument.
* A shared libmysqld embedded server library was not built on Linux.
* While printing the server version, the mysql client did not check for buffer overflow in a string variable.
* Contraction information in a collation could be mishandled, resulting in incorrect decisions about whether a character is part of a contraction, and miscalculation of contraction weights.
* DROP TRIGGER succeeded even with the read_only system variable enabled.
* Updating the Performance Schema setup_instruments table on a replication master caused a slave to exit.
* Due to a race condition, it was possible for two threads to end up with the same query ID for different queries.
* When run by root, mysqld --help --verbose exited with a nonzero error code after displaying the help message.
* MySQL client programs from a Community Edition distribution could not connect using SSL to a MySQL server from an Enterprise Edition. This was due to a difference in certificate handling by yaSSL and OpenSSL (used for Community and Enterprise, respectively). OpenSSL expected a blank certificate to be sent when not all of the --ssl-ca, --ssl-cert, and --ssl-key options were specified, and yaSSL did not do so. To resolve this, yaSSL has been modified to send a blank certificate when an option is missing.
* A deadlock error occurring during subquery execution could cause an assertion to be raised.
* The Performance Schema stage/sql/Waiting to get readlock instrument is no longer used and has been removed.
* For system variables that take a string value, SET statements permitted an unquoted value, but values that contained dots were parsed incorrectly and only part of the value was assigned. For example, SET GLOBAL slow_query_log_file = my_slow.log assigned the value my_slow. Now such values must be quoted or an error occurs.

# Functionality Added or Changed
* Previously, ALTER TABLE in MySQL 5.6 could alter a table such that the result had temporal columns in both 5.5 and 5.6 format. Now ALTER TABLE upgrades old temporal columns to 5.6 format for ADD COLUMN, CHANGE COLUMN, MODIFY COLUMN, ADD INDEX, and FORCE operations. This conversion cannot be done using the INPLACE algorithm, so specifying ALGORITHM=INPLACE in these cases results in an error.
* CMake now supports a -DTMPDIR=dir_name option to specify the default tmpdir value. If unspecified, the value defaults to P_tmpdir in <stdio.h>. Thanks to Honza Horak for the patch.
# Bugs Fixed
* InnoDB; Replication: Using the InnoDB memcached plugin (see InnoDB Integration with memcached) with innodb_api_enable_binlog set to 1 caused the server to leak memory.
* InnoDB: A boolean mode full-text search query would result in a memory access violation during parsing.
* InnoDB: When new indexes are added by an ALTER TABLE operation, instead of only saving table-level statistics and statistics for the new indexes, InnoDB would save statistics for the entire table, including the table's other indexes. This behavior slowed ALTER TABLE performance.
* InnoDB: Due to a parser error, full-text search queries that include a sub-expression could return the wrong result.
* InnoDB: The innochecksum tool did not use a Windows-specific API to retrieve file size information, which resulted in an incorrect error message (Error: ibdata1 cannot be found) when the MySQL 5.6 innochecksum 2GB file size limit was exceeded. innochecksum now provides support for files larger than 2GB in both MySQL 5.6 and MySQL 5.7.
* InnoDB: Due to a regression introduced by the fix for Bug#17371537, memory was not allocated for the default memcached engine when using the default memcached engine as the backstore for data instead of InnoDB.
* InnoDB: InnoDB would report an incorrect operating system error code after failing to initialize.
* InnoDB: Manipulating a table after discarding its tablespace using ALTER TABLE ... DISCARD TABLESPACE could result in a serious error.
* InnoDB: Persistent optimizer statistics would cause stalls due to latch contention.
* InnoDB: MATCH() ... AGAINST queries that use a long string as an argument for AGAINST() could result in an error when run on an InnoDB table with a full-text search index.
* InnoDB: An InnoDB full-text search failure would occur due to an “unended” token. The string and string length should be passed for string comparison.
* InnoDB: In debug builds, a merge insert buffer during a page read would cause a memory access violation.
* InnoDB: Truncating a memcached InnoDB table while memcached is performing DML operations would result in a serious error.
* InnoDB: In sync0rw.ic, rw_lock_x_lock_func_nowait would needlessly call os_thread_get_curr_id.
* InnoDB: Attempting to rename a table to a missing database would result in a serious error.
* InnoDB: If a tablespace data file path is updated in a .isl file and then a crash recovery is performed, the updated tablespace data file path is read from the .isl file but the SYS_DATAFILES table would not be not updated. The SYS_DATAFILES table is now updated with the new data file path after crash recovery.
* InnoDB: If the first page (page 0) of file-per-table tablespace data file was corrupt, recovery would be halted even though the doublewrite buffer contained a clean copy of the page.
* InnoDB: The InnoDB memcached Readme file (README-innodb_memcached) incorrectly stated that libevent 1.6.0 is linked statically into daemon memcached. The bundled version of libevent is 1.4.12, not 1.6.0.
* InnoDB: Attempting to reset a replication slave while innodb_force_recovery is greater than 0 would return a cryptic error message: ERROR(1030) HY000: Got error -1 from storage engine. The error message has been changed to: ERROR HY000: Operation not allowed when innodb_force_recovery > 0. Replication options such as --relay-log-info-repository=TABLE and --master-info-repository=TABLE store information in tables in InnoDB. When innodb_force_recovery is greater than 0, replication tables cannot be updated which may cause replication administration commands to fail.
* InnoDB: The ALTER TABLE INPLACE algorithm would fail to decrease the auto-increment value.
* InnoDB: Comments in btr0cur.cc incorrectly stated that btr_cur_pessimistic_update() and btr_cur_optimistic_update() would accept a NULL value.
* InnoDB: dict_table_schema_check would call dtype_sql_name needlessly.
* InnoDB: The function os_file_get_status would not work with raw devices.
* InnoDB: During crash recovery, an incorrect transaction active time would result in rolling back an uncommitted transaction.
* InnoDB: Heap block debugging information (file_name, lineno), used for logging diagnostics, would appear in release builds. This information should only appear in debug builds.
* InnoDB: Renaming a column while also adding or dropping columns in the same ALTER TABLE operation would cause an error.
* InnoDB: An online ALTER TABLE operation would consume more memory than expected. During an online ALTER TABLE operation, an online log buffer containing a head and tail buffer is created for each index that is created or rebuilt. The tail buffer is the writer context and is only required for concurrent write operations on an index while the ALTER TABLE operation is in progress. The head buffer is the reader context and is only required during the log apply phase. To reduce memory consumption, the tail buffer is now allocated when the first DML statement is run on the index, and the head buffer is only allocated in the log apply phase and freed afterwards.
* InnoDB: On Windows, the full-text search (FTS) object ID was not in the expected hexadecimal format.
* InnoDB: Fetching and releasing pages from the buffer pool and tracking the page state are expensive and complex operations. Prior to the bug fix, these operations were performed using a page mutex. Using a page mutex to track several things is expensive and does not scale well. The bug fix separates fetch and release tracking (in-use state) of a page from page I/O state tracking. Fetch and release is now tracked using atomics where available.
* InnoDB: Table renaming errors would appear in the LATEST FOREIGN KEY ERROR section of the SHOW ENGINE INNODB STATUS output.
* InnoDB: UNIV_SYNC_DEBUG, which was disabled in univ.i with the fix for Bug#16720368, is now enabled.
* Partitioning: Queries using the index_merge optimization (see Index Merge Optimization) could return invalid results when run against tables that were partitioned by HASH.
* Partitioning: When no partition had returned a row since the last HA_ERR_KEY_NOT_FOUND error, the use of uninitialized memory in the priority queue used for returning rows in sorted order could lead to a crash of the server.
* Replication: When the binary log I/O cache grew to exactly 32768 bytes and the current transaction was preceded by a transaction whose size was greater than 32768 bytes, events could be corrupted when written into the binary log.
* Replication: Creating and dropping large numbers of temporary tables could lead to increased memory consumption.
* Replication: mysqlbinlog --verbose failed when it encountered a corrupt row event in the binary log. Such a row event could also cause the slave to fail.
* Replication: When log_warnings is greater than 1, the master prints binary log dump thread information—containing the slave server ID, binary log file name, and binary log position—in mysqld.1.err. A slave server ID greater than 2 billion was printed with a negative value in such cases.
* Replication: mysqlbinlog did not properly decode DECIMAL values in a row-based binary log. This could cause invalid values to be printed out for DECIMAL columns.
* Replication: Seconds_Behind_Master in the output of SHOW SLAVE STATUS could under some conditions be reported as 0 when it should have had a value greater than zero.
* Replication: The semisynchronous replication plugin was called twice for a DDL statement, incrementing Rpl_semi_sync_master_yes_tx by 2 instead of 1 each time such a statement was executed.
* Compilation errors occurred on Solaris 10; resolved by including my_config.h before system header files.
* FORCE INDEX [FOR ORDER BY] (index_name) did not work for joins.
* With the compressed client/server protocol enabled, Performance Schema statement instrumentation could raise an assertion.
* In some cases, UNIX_TIMESTAMP() could return NULL when it should return 0.
* An assertion could be raised if a filesort failed to resize its main buffer when record properties changed.
* The cache used for the Index Merge access method was freed only after successful retrieval of all rows. Interruption or failure of the operation led to a file descriptor leak.
* Using the mysqldump --set-gtid-purged option with no value caused mysqldump to crash.
* A race condition between Performance Schema statement event threads led to a server exit.
* In a view definition requireing resolution of aggregrate expressions within a subquery to an outer query, selecting from the view could cause a server exit.
* An addressing error in accessing the join buffer could produce invalid results or a server exit.
* mysql_config incorrectly included some flags to generate compiler warning output.
* With semi-join optimization enabled, queries with nested subqueries could cause a server exit due to incorrect resolution of references to columns in the middle query block.
* In some cases, the optimizer wrote fixed-length temporary MyISAM tables to disk rather than variable-length temporary tables.
* Enabling the validate_password plugin could result in incorrect password hashes being stored in the mysql.user table.
* For accounts authenticated using the sha256_password plugin, setting the password after the password had been expired did not clear the password-expired flag.
* On Mac OS X 10.7, a race condition involving vio_shutdown() and the select-based implementation of vio_io_wait() could cause a server exit.
* Host names in example URLs used within the source code were replaced by names in the example.com domain, the domain intended by IANA for this purpose.
* For utf8 and utf8mb4 strings, handler functions unnecessarily called a Unicode conversion function.
* Several -W warning flags were turned off for compilation in maintainer mode if MySQL was configured with -DWITH_INNODB_MEMCACHED=1.
* Calling the ExtractValue() function with an invalid XPath expression could in some cases lead to a failure of the server.
* Use of a nonmulti-byte algorithm for skipping leading spaces in multi-byte strings could cause a server exit.
* With ONLY_FULL_GROUP_BY SQL mode enabled, a query that uses GROUP BY on a column derived from a subquery in the FROM clause failed with a column isn't in GROUP BY error, if the query was in a view.
* For the utf8_bin collation, ORDER BY LOWER(col_name) could produce incorrect ordering.
* Several issues identified by the Coverity static analysis tool were fixed. Thanks to Honza Horak for the patch.
* On Windows, the --local-service server option did not work, and was not displayed in the --help message.
* It was not possible to query a view with an ORDER BY clause that referenced an alias in the SELECT clause of the view definition, unless all columns in the view were named in the select list.
* To handle this problem, the server now writes a view differently into the .frm file that stores the view definition. If you experience view-evaluation errors such as just described, drop and recreate the view so that the .frm file contains the updated view representation.
* The prototype of the Performance Schema instrumentation API mysql_cond_timedwait() call was fixed to be drop-in compatible with pthread_cond_timedwait(). This fix affects only implementers of third-party plugins.
* The make_atomic_cas_body64 implementation on IA32 with gcc but without gcc builtins could be miscompiled due to an incorrect constraint. The patch also causes MySQL to use builtin atomics when compiled using Clang.
* Complex updates of Performance Schema tables involving joins or subqueries failed to update every row.
* For the path specified with the --basedir option, mysql_plugin attempted to unlink the path rather than free the memory in which the path was stored.
* COUNT(DISTINCT) sometimes produced an incorrect result when the last read row contained a NULL value.
* sql_resolver.cc referred to partitioning code that should have been protected by an #ifdef, even when MySQL was configured with -DWITH_PARTITION_STORAGE_ENGINE=OFF.
* In incorrect result could be returned for a query with an IF() predicate in the WHERE clause combined with OUTER JOIN in a subquery that is transformed to a semi-join. (A workaround is to disable semi-join using SET optimizer_switch='semijoin=off';)
* A full-text search combined with derived tables (subqueries in the FROM clause) caused a server exit.
* Now if a full-text operation depends on a derived table, the server produces an error indicating that a full-text search cannot be done on a materialized table.
* Some scripts displayed out-of-date information regarding where to report bugs.
* Some files in the Performance Schema file_instances table were not being removed because the file-removal operation was not instrumented.
* mysqldump --single-transaction acquired metadata locks for each dumped table but did not release them until the dump operation finished. Consequently, other DDL operations on a dumped table blocked even after the table itself had been dumped. mysqldump now attempts to release metadata locks earlier.
* Updating a FEDERATED table with UPDATE... JOIN caused a server exit when the local table contained a single row and that row could be joined to a row in the FEDERATED table.
* mysql_install_db referred to the obsolete mysqlbug script for reporting problems.

# Functionality Added or Changed
* CMake now supports a -DTMPDIR=dir_name option to specify the default tmpdir value. If unspecified, the value defaults to P_tmpdir in <stdio.h>. Thanks to Honza Horak for the patch.
# Bugs Fixed
* InnoDB: Table renaming errors would appear in the LATEST FOREIGN KEY ERROR section of the SHOW ENGINE INNODB STATUS output.
* Partitioning: Queries using the index_merge optimization (see Index Merge Optimization) could return invalid results when run against tables that were partitioned by HASH.
* Partitioning: When no partition had returned a row since the last HA_ERR_KEY_NOT_FOUND error, the use of uninitialized memory in the priority queue used for returning rows in sorted order could lead to a crash of the server.
* Replication: mysqlbinlog --verbose failed when it encountered a corrupt row event in the binary log. Such a row event could also cause the slave to fail.
* Replication: When log_warnings is greater than 1, the master prints binary log dump thread information—containing the slave server ID, binary log file name, and binary log position—in mysqld.1.err. A slave server ID greater than 2 billion was printed with a negative value in such cases.
* Replication: Invalid event offsets in the binary log were not always handled correctly, which could lead to replication failure.
* The cache used for the Index Merge access method was freed only after successful retrieval of all rows. Interruption or failure of the operation led to a file descriptor leak.
* For utf8 and utf8mb4 strings, handler functions unnecessarily called a Unicode conversion function.
* Use of a nonmulti-byte algorithm for skipping leading spaces in multi-byte strings could cause a server exit.
* For the utf8_bin collation, ORDER BY LOWER(col_name) could produce incorrect ordering.
* On Windows, the --local-service server option did not work, and was not displayed in the --help message.
* The prototype of the Performance Schema instrumentation API mysql_cond_timedwait() call was fixed to be drop-in compatible with pthread_cond_timedwait(). This fix affects only implementers of third-party plugins.
* For the path specified with the --basedir option, mysql_plugin attempted to unlink the path rather than free the memory in which the path was stored.
* COUNT(DISTINCT) sometimes produced an incorrect result when the last read row contained a NULL value.
* Some scripts displayed out-of-date information regarding where to report bugs.
* Updating a FEDERATED table with UPDATE... JOIN caused a server exit when the local table contained a single row and that row could be joined to a row in the FEDERATED table.
* mysql_install_db referred to the obsolete mysqlbug script for reporting problems.

# Bugs Fixed
* InnoDB: A regression fix resulted a memory leak for memcached insert operations.
* InnoDB: The trx->error_key_num field was not initialized in the error injection code found in storage/innobase/handler/handler0alter.cc. The error_key_num field is usually 0 but can be a non zero value if the memory buffer of a DDL transaction object is reused.
* InnoDB: Fault-tolerant code found in the log apply code for InnoDB ALTER TABLE ... IN PLACE could result in data corruption.
* InnoDB: Databases names beginning with a digit would cause a full-text search (FTS) parser error.
* InnoDB: An ALTER TABLE ... CHANGE [COLUMN] operation would result in an rbt_empty(index_cache->words) assertion.
* InnoDB: Running SHOW ENGINE INNODB STATUS on one connection thread and killing that thread by running a KILL CONNECTION statement from a different connection thread would result in a severe error.
* InnoDB: An excessive amount of memory would be consumed when querying INFORMATION_SCHEMA.INNODB_FT_INDEX_TABLE. The problem would occur for very large full-text search indexes.
* InnoDB: CHECK TABLE would ignore the QUICK option.
* InnoDB: The information_schema.innodb_metrics index_merge counter was not incremented in btr0btr.cc. This patch also introduces new counters (index_page_reorg_attempts, index_page_reorg_successful and index_page_discards) and renames the index_merges counter to “index_page_merge_attempts” to distinguish it from the index_page_merge_successful counter.
* InnoDB: Setting the O_DIRECT flag on a file on tmpfs on some operating systems would result in an error printed to the error log. Creating multiple temporary tables on tmpfs would cause the error to be printed repeatedly. The error message has been changed to a warning that is only printed once when running CREATE TABLE multiple times.
* InnoDB: In debug builds, test case failures would occur due to ibuf_contract_ext performing merges and dict_stats_update returning evicted pages back into the buffer pool while ibuf_change_buffering_debug is enabled.
* InnoDB: InnoDB would fail to return an error when attempting to run a query after discarding the tablespace.
* InnoDB: A severe error would occur after discarding a tablespace.
* InnoDB: During a TRUNCATE TABLE operation, InnoDB: Trying to TRUNCATE a missing index of table ... warnings would be printed to the error log. These warnings should not be printed when the index is a full-text search (FTS) index.
* InnoDB: Full-text index creation on a large table would fail due to insufficient temporary table space and result in a misleading “incorrect key file” error.
* InnoDB: The InnoDB mecached plugin would update a record before inserting to the binlog, which would cause slave server replication to stop. The insert should occur before the update.
* InnoDB: During parallel full-text search (FTS) index creation, a scanner thread reads in documents and passes them to the tokenizer. The tokenizer frees documents from memory when tokenization is complete. When tokenizing documents with a large amount of text, the tokenizer thread would not keep pace with the scanner thread. As a result, memory would not be freed fast enough and the “tokenization pending list” would grow in size.
* InnoDB: A full-text search (FTS) BOOLEAN MODE query with an invalid character in the query string could result in a memory access violation failure.
* InnoDB: trx_create and trx_free would be called for every memcached get request.
* InnoDB: The hardcoded size for the srv_max_n_threads variable was insufficient. The variable setting is now configured based on the maximum number of connection threads and InnoDB background threads.
* InnoDB: In btr_validate_level there are checks to ensure that all B-tree pages are marked when allocated. The checks would fail on the change buffer because the allocation of change buffer pages is handled differently than other B-tree pages.
* InnoDB: When the change buffer is enabled, InnoDB would fail to write a transaction log record when merging a record from the insert buffer to a secondary index page if the insert was performed as an “update-in-place”.
* InnoDB: A SELECT COUNT (*) query would run very slowly when run concurrently with a LOAD DATA operation.
* InnoDB: An existing full-text index would become invalid after running ALTER TABLE ADD FULLTEXT due to an unsynchronized full-text cache.
* InnoDB: Due to a regression in MySQL 5.6, creating or dropping tables with innodb_force_recovery set to 3 (SRV_FORCE_NO_TRX_UNDO) would fail. Additionally, this bug fix includes a code modification that sets InnoDB to read-only when innodb_force_recovery is set to a value greater than 3 (SRV_FORCE_NO_TRX_UNDO).
* InnoDB: An InnoDB memcached configuration error message contained an incorrect file name. The error message stated, Please create config table containers in database innodb_memcache by running innodb_config.sql. error 31. The correct file name is innodb_memcached_config.sql. Also, the “error 31” portion of the error message has been translated to its text equivalent, which is “Table not found”.
* InnoDB: In mutex_spin_wait(), the sync_array_reserve_cell function could fail to find an empty slot on systems with sync wait arrays that are small in size, resulting in an error.
* InnoDB: When index_read_map is called for an exact search and fails to return a record due to non-matching search criteria, the cursor would be positioned on the next record after the searched key. A subsequent call to index_next would return the next record instead of returning the previous non-matching row, thereby skipping a record.
* InnoDB: Full-text search (FTS) index savepoint information would not be set resulting in a severe error when attempting to rollback to the savepoint.
* InnoDB: Converting a table with a large number of columns from MyISAM to InnoDB would cause an assertion due to insufficient log buffer space. Instead of asserting, InnoDB now attempts to increase log buffer size automatically if the redo log size is too large.
* Partitioning: The storage engine was set incorrectly during a rebuild of a partition; the table storage engine was ignored and the default storage engine used instead. Thus, in MySQL 5.1, it was possible for REBUILD PARTITION to change the partition storage engine from InnoDB to MyISAM, and for the reverse (rebuilding partitions of MyISAM tables causing the partitions to use InnoDB) to occurin MySQL 5.5 and later. Now, when rebuilding partitions, the storage engine actually used by the table is checked and used by the handler for the rebuild operation, so that the partition storage engine is not inadvertently changed.
* Partitioning: After disabling the parent table's indexes with ALTER TABLE ... DISABLE KEYS, rebuilding any of its partitions enabled the indexes on those partitions, leading MyISAM to fail with an error when the optimizer tried to use one of the affected indexes.
* Replication: A replication master did not handle correctly the disabling of the semisync plugin on the master and the slave, with a subsequent stopping of the slave.
* Replication: The final argument in the SET clause of a LOAD DATA ... SET statement was repeated in the binary log.
* Replication: When an error encountered by the dump thread while reading events from the active binary log file was a temporary error, so that the dump thread tried to read the event, it was possible for the dump thread to seek the wrong position, which could cause one or more events to be resent. To prevent this, the thread's position is obtained after each correct read of an event.
* Replication: When stopping the I/O thread, it was possible with a very large transaction (equivalent to a binary log size greater than 100MB) that the thread did not receive the transaction to the end. When reconnecting with MASTER_AUTO_POSITION=1 it then tried to fetch changes from the next transaction, which could lead to loss of the incomplete transaction and its data.
* Replication: Setting rpl_semi_sync_master_enabled while the master was waiting for a reply from the slave could in some cases cause the master to fail.
* Replication: Trying to set CHANGE MASTER TO ... MASTER_AUTO_POSITION = 0 failed with error 1777 (ER_AUTO_POSITION_REQUIRES_GTID_MODE_ON).
* Replication: The value of LAST_INSERT_ID() was not correctly replicated when filtering rules were used on the slave.
* Replication: An internal function used for storing GTID values could sometimes try to handle them as strings of the wrong length.
* Replication: During row-based replication with binlog_row_image set to MINIMAL, updating only some columns of a table having 9 or more columns caused mysqlbinlog to fail when it was used with the --verbose option.
* Replication: Issuing a GRANT statement with invalid parameters caused the master to write LOST_EVENTS events into its binary logs, causing replication to stop. Now such cases, if one or more grants or revocations of privileges are successful, an incident is written to the log; otherwise, only a warning is logged.
* libmysqlclient version 18 files were removed from MySQL-shared-compat RPM packages to avoid a conflict between the MySQL-shared and MySQL-shared-compat RPM packages.
* Enabling Index Merge optimizer switches and setting a small sort_buffer_size value could lead to a server exit.
* Semi-join materialization strategy was not used for VARCHAR columns longer than 512 bytes, resulting in use of a less-efficient strategy and worse query performance. (The limit in characters rather than bytes depends on the column character set; 170 characters for utf8, for example.)
* Some license and documentation files were missing from Windows MSI packages.
* Selecting from the Performance Schema session_connect_attrs table under high load could cause a server exit.
* Compilation failures under Visual Studio 2012 were corrected.
* The CLIENT_CONNECT_WITH_DB flag was improperly handled in the C client library. This could lead to a malformed packet sent to the server.
* An assertion was raised if SET PASSWORD was used for an account that has been manually deleted from the mysql.user table but still present in memory.
* The mysql_options() C API function could leak memory if called more than once with the MYSQL_SET_CLIENT_IP option.
* The CONV() function could call abs(INT_MIN), which is undefined, and cause a server exit.
* An error array in the SSL code was missing a comma, leading to implicit concatenation of adjacent messages and a resulting off-by-one error in the relationship between error numbers and messages.
* The filesort implementation sometimes failed to allocate enough buffer space, leading to a server exit.
* GRANT without an IDENTIFIED BY clause resulted in an error even for existing users.
* GROUP_CONCAT() with an invalid separator could cause a server exit.
* An internal InnoDB string routine could write past the end of a buffer.
* GIS intersection-related code was missing a return value check, leading to a loop in nondebug builds and a raised assertion in debug builds.
* Using the binary client/server protocol, the second execution of a prepared statement for a query with parameters in the LIMIT clause raised an assertion.
* For upgrades using the Windows MSI package installer, the upgrade dialog message was missing the “from” version.
* Very long database names in queries could cause the server to exit.
* Standalone Windows MSI packages did not have the ALLUSERS property set. They now set ALLUSERS=1. For earlier MSI packages in this MySQL series, a workaround is to use the following command:
- C:> msiexec /i msi_installer_name ALLUSERS=1
* Recursion by functions called as arguments to XPath expressions was not handled correctly, sometimes causing such expressions to fail.
* For an ALTER TABLE statement that renamed or changed the default value of a BINARY column, the alteration was done using a table copy and not in place.
* Some possible cases of memory use after being freed were fixed. Thanks to Jan Staněk for the patch.
* In debug builds, static initialization code could call DBUG functions before the DBUG subsystem was initialized.
* With the thread pool plugin enabled, the the PROCESSLIST_USER and PROCESSLIST_HOST columns of the Performance Schema threads table were always NULL for client sessions. Also, for the main thread, those columns were not NULL but set to a user account.
* COUNT(DISTINCT) should not count NULL values, but they were counted when the optimizer used Loose Index Scan.
* For queries of the form UPDATE ... WHERE unique_key ORDER BY ... LIMIT ..., incorrect rows could be updated. Unique keys permit multiple NULL values, but the optimizer did not always consider all of them.
* If asked to upgrade a server that was running without InnoDB enabled, mysql_upgrade issued complaints about InnoDB tables not existing (tables that will not exist unless InnoDB is available).
* In some cases, range conditions over indexes defined on column prefixes returned incomplete result sets. (For example, SELECT ... WHERE 'abcdef1' < col_name AND col_name < 'abcdef9', where the index on col_name indexed only the first 6 characters.)
* Performance Schema instrumentation overhead was reduced for frequent connect/disconnect operations.
* Setting host_cache_size at startup had no effect.
* InnoDB full-text searches failed to find records within transactions that included savepoints.
* Some INSERT INTO ... SELECT ... FROM statements were slow unless the tmp_table_size and max_heap_table_size system variables were set large enough to permit the temporary table used for query processing to be stored in the MEMORY storage engine.
* Incorrect reference counting in the range optimizer module resulted in potential for missing or duplicate rows in the query result set.
* Host names in grant tables are stored in lowercase, but mysql_install_db could fail to observe this convention, leading to accounts that could not be dropped with DROP USER.
* The server uses the ethernet hardware address for UUID generation, but made assumptions about the names of ethernet devices rather than querying the system for their names.
* Several issues identified by the Coverity static analysis tool were fixed. Thanks to Jan Staněk and Honza Horak for the patches.
* Missing va_end() calls were added to logging and UCS2 code. Thanks to Jan Staněk for the patch.
* MySQL did not compile on Mac OS X 10.9 (Mavericks).
* Killing a query that is performing a filesort operation resulted in an ER_SERVER_SHUTDOWN (Server shutdown in progess) error.

# Functionality Added or Changed
* A new CMake option, WITH_ASAN, permits enabling address sanitization for compilers that support it.
* Attempts to use the thread_concurrency system variable (which has an effect only for Solaris 8 and earlier) now indicate that it has no effect when that is the case.
# Bugs Fixed
* InnoDB: Running SHOW ENGINE INNODB STATUS on one connection thread and killing that thread by running a KILL CONNECTION statement from a different connection thread would result in a severe error.
* InnoDB: CHECK TABLE would ignore the QUICK option.
* InnoDB: In debug builds, test case failures would occur due to ibuf_contract_ext performing merges and dict_stats_update returning evicted pages back into the buffer pool while ibuf_change_buffering_debug is enabled.
* InnoDB: InnoDB would fail to return an error when attempting to run a query after discarding the tablespace.
* InnoDB: When the change buffer is enabled, InnoDB would fail to write a transaction log record when merging a record from the insert buffer to a secondary index page if the insert was performed as an “update-in-place”.
* InnoDB: When index_read_map is called for an exact search and fails to return a record due to non-matching search criteria, the cursor would be positioned on the next record after the searched key. A subsequent call to index_next would return the next record instead of returning the previous non-matching row, thereby skipping a record.
* InnoDB: Converting a table with a large number of columns from MyISAM to InnoDB would cause an assertion due to insufficient log buffer space. Instead of asserting, InnoDB now attempts to increase log buffer size automatically if the redo log size is too large.
* Partitioning: After disabling the parent table's indexes with ALTER TABLE ... DISABLE KEYS, rebuilding any of its partitions enabled the indexes on those partitions, leading MyISAM to fail with an error when the optimizer tried to use one of the affected indexes.
* Replication: A replication master did not handle correctly the disabling of the semisync plugin on the master and the slave, with a subsequent stopping of the slave.
* Replication: The final argument in the SET clause of a LOAD DATA ... SET statement was repeated in the binary log.
* Replication: When an error encountered by the dump thread while reading events from the active binary log file was a temporary error, so that the dump thread tried to read the event, it was possible for the dump thread to seek the wrong position, which could cause one or more events to be resent. To prevent this, the thread's position is obtained after each correct read of an event.
* Replication: Setting rpl_semi_sync_master_enabled while the master was waiting for a reply from the slave could in some cases cause the master to fail.
* Replication: The value of LAST_INSERT_ID() was not correctly replicated when filtering rules were used on the slave.
* Enabling Index Merge optimizer switches and setting a small sort_buffer_size value could lead to a server exit.
* Some license and documentation files were missing from Windows MSI packages.
* The mysql_options() C API function could leak memory if called more than once with the MYSQL_SET_CLIENT_IP option.
* The CONV() function could call abs(INT_MIN), which is undefined, and cause a server exit.
* An error array in the SSL code was missing a comma, leading to implicit concatenation of adjacent messages and a resulting off-by-one error in the relationship between error numbers and messages.
* The filesort implementation sometimes failed to allocate enough buffer space, leading to a server exit.
* GROUP_CONCAT() with an invalid separator could cause a server exit.
* An internal InnoDB string routine could write past the end of a buffer.
* Using the binary client/server protocol, the second execution of a prepared statement for a query with parameters in the LIMIT clause raised an assertion.
* The usual failed-login attempt accounting was not applied to failed COM_CHANGE_USER commands.
* Very long database names in queries could cause the server to exit.
* Standalone Windows MSI packages did not have the ALLUSERS property set. They now set ALLUSERS=1. For earlier MSI packages in this MySQL series, a workaround is to use the following command:
- C:> msiexec /i msi_installer_name ALLUSERS=1
* The my_b_vprintf() function could produce incorrect results for long integers on 64-bit systems.
* COUNT(DISTINCT) should not count NULL values, but they were counted when the optimizer used Loose Index Scan.
* For queries of the form UPDATE ... WHERE unique_key ORDER BY ... LIMIT ..., incorrect rows could be updated. Unique keys permit multiple NULL values, but the optimizer did not always consider all of them.
* Host names in grant tables are stored in lowercase, but mysql_install_db could fail to observe this convention, leading to accounts that could not be dropped with DROP USER.
* Killing a query that is performing a filesort operation resulted in an ER_SERVER_SHUTDOWN (Server shutdown in progess) error.

# Bugs Fixed
* InnoDB: In debug builds, test case failures would occur due to ibuf_contract_ext performing merges and dict_stats_update returning evicted pages back into the buffer pool while ibuf_change_buffering_debug is enabled.
* InnoDB: InnoDB would fail to return an error when attempting to run a query after discarding the tablespace.
* InnoDB: When the change buffer is enabled, InnoDB would fail to write a transaction log record when merging a record from the insert buffer to a secondary index page if the insert was performed as an “update-in-place”.
* Partitioning: The storage engine was set incorrectly during a rebuild of a partition; the table storage engine was ignored and the default storage engine used instead. Thus, in MySQL 5.1, it was possible for REBUILD PARTITION to change the partition storage engine from InnoDB to MyISAM, and for the reverse (rebuilding partitions of MyISAM tables causing the partitions to use InnoDB) to occurin MySQL 5.5 and later. Now, when rebuilding partitions, the storage engine actually used by the table is checked and used by the handler for the rebuild operation, so that the partition storage engine is not inadvertently changed.
* Replication: When an error encountered by the dump thread while reading events from the active binary log file was a temporary error, so that the dump thread tried to read the event, it was possible for the dump thread to seek the wrong position, which could cause one or more events to be resent. To prevent this, the thread's position is obtained after each correct read of an event.
* Replication: The value of LAST_INSERT_ID() was not correctly replicated when filtering rules were used on the slave.
* Enabling Index Merge optimizer switches and setting a small sort_buffer_size value could lead to a server exit.
* The mysql_options() C API function could leak memory if called more than once with the MYSQL_SET_CLIENT_IP option.
* An error array in the SSL code was missing a comma, leading to implicit concatenation of adjacent messages and a resulting off-by-one error in the relationship between error numbers and messages.
* The filesort implementation sometimes failed to allocate enough buffer space, leading to a server exit.
* Very long database names in queries could cause the server to exit.
* The my_b_vprintf() function could produce incorrect results for long integers on 64-bit systems.
* Host names in grant tables are stored in lowercase, but mysql_install_db could fail to observe this convention, leading to accounts that could not be dropped with DROP USER.

# Functionality Added or Changed
* comp_err now checks to make sure that new errors are not being added to MySQL 5.1 or 5.5 because the set of errors for these series is frozen.
# Bugs Fixed
* InnoDB: During an insert buffer merge, InnoDB would invoke lock_rec_restore_from_page_infimum() on a potentially invalid record pointer.
* InnoDB: The page_zip_validate() consistency check would fail after compressing a page, in page_zip_compress(). This problem was caused by page_zip_decompress(), which would fail to set heap_no correctly when a record contained no user data bytes. A record with no user data bytes occurs when, for example, a primary key is an empty string and all secondary index fields are NULL or an empty string.
* InnoDB: The pthread_mutex, commit_threads_m, which was initialized but never used, has been removed from the code base.
* Partitioning: When dropping a partitioned table, the table's .par file was deleted first, before the table definition or data. This meant that, if the server failed during the drop operation, the table could be left in an inconsistent state in which it could neither be accessed nor dropped.
* Shared-compatibility conflict errors occurred for RPM install operations, even if no shared-compatibility RPMs were already installed.
* A user variable referenced during execution of a prepared statement is set to memory that is freed at the end of execution. A second execution of the statement could result in Valgrind warnings when accessing this memory.
* Misoptimization of left expressions in prepared statements could cause a server exit.
* Subsequent to Prepared statement needs to be re-prepared errors, inserts into DECIMAL columns caused a server exit.
* Assigning the result of a subquery to a user variable raised an assertion when the outer query included DISTINCT and GROUP BY.

# Functionality Added or Changed
* Important Change; Replication: By default, when promoting integers from a smaller type on the master to a larger type on the slave (for example, from a SMALLINT column on the master to a BIGINT column on the slave), the promoted values are treated as though they are signed. Now in such cases it is possible to modify or override this behavior using one or both of ALL_SIGNED, ALL_UNSIGNED in the set of values specified for the slave_type_conversions server system variable. For more information, see Row-based replication: attribute promotion and demotion, as well as the description of the variable.
* Previously, program options could be specified in full or as any unambiguous prefix. For example, the --compress option could be given to mysqldump as --compr, but not as --comp because the latter is ambiguous. Option prefixes now are deprecated. They can cause problems when new options are implemented for programs. A prefix that is currently unambiguous might become ambiguous in the future. If an unambiguous prefix is given, a warning now occurs to provide feedback. For example: Warning: Using unique option prefix compr instead of compress is deprecated and will be removed in a future release. Please use the full name instead. Option prefixes are no longer supported in MySQL 5.7; only full options are accepted.
* The C API libmysqlclient shared-library .so files now have version 18.1.0 (up from version 18.0.0 used in MySQL 5.5).
* In batch mode, mysql formatted result status messages such as “"Query OK, 1 row affected"” but did not print them. Now these messages are not formatted.
# Bugs Fixed
* Performance; Important Change; InnoDB: InnoDB would fail to open a tablespace that has multiple data files. This removes the known limitation that was in MySQL Server 5.6.12.
* Performance; InnoDB: A code regression introduced in MySQL 5.6 negatively impacted DROP TABLE and ALTER TABLE performance. This could cause a performance drop between MySQL Server 5.5.x and 5.6.x.
* Performance; InnoDB: When innodb_thread_concurrency is set to a non-zero value, there was a possibility that all innodb_concurrency_tickets would be released after each row was read, resulting in a concurrency check after each read. This could impact performance of all queries. One symptom could be higher system CPU usage. We strongly recommend that you upgrade to MySQL Server 5.6.13 if you use this setting. This could cause a performance drop between MySQL Server 5.5.x and 5.6.x.
* Incompatible Change: It is possible for a column DEFAULT value to be valid for the sql_mode value at table-creation time but invalid for the sql_mode value when rows are inserted or updated.
* MySQL Cluster: CREATE LOGFILE GROUP failed with a syntax error when INITIAL_SIZE, UNDO_BUFFER_SIZE, or both options were specified.
* InnoDB: The server would crash during a memcached set operation. The failure was due to a padded length value for a utf8 char column. During a memcached update operation, a field from an old tuple would be copied with a data length that was less than the padded utf8 char column value. This fix ensures that old tuples are not copied. Instead, a new tuple is created each time.
* InnoDB: When CHECK TABLE found a secondary index that contained the wrong number of entries, it would report an error but not mark the index as corrupt. CHECK TABLE now marks the index as corrupt when this error is encountered, but only the index is marked as corrupt, not the table. As a result, only the index becomes unusable until it is dropped and rebuilt. The table is unaffected.
* InnoDB: InnoDB would attempt to gather statistics on partially created indexes.
* InnoDB: A full-text search using the IN BOOLEAN MODE modifier would result in an assertion failure.
* InnoDB: The two INFORMATION_SCHEMA tables for the InnoDB buffer pool could show an invalid page type for read-fixed blocks. This fix will show the unknown page type for blocks that are I/O-fixed for reading.
* InnoDB: During an insert buffer merge, InnoDB would invoke lock_rec_restore_from_page_infimum() on a potentially invalid record pointer.
* InnoDB: The innodb_rwlock_x_spin_waits item in the INFORMATION_SCHEMA.INNODB_METRICS table would show the same value as the innodb_rwlock_x_os_waits item.
* InnoDB: A memory leak would occur when inserting or replacing a row in a full-text search index on a table with more than 96 columns.
* InnoDB: In debug builds, an assertion could occur in OPT_CHECK_ORDER_BY when using binary directly in a search string, as binary may include NULL bytes and other non-meaningful characters. This fix will remove non-meaningful characters before the search is run.
* InnoDB: The page_zip_validate() consistency check would fail after compressing a page, in page_zip_compress(). This problem was caused by page_zip_decompress(), which would fail to set heap_no correctly when a record contained no user data bytes. A record with no user data bytes occurs when, for example, a primary key is an empty string and all secondary index fields are NULL or an empty string.
* InnoDB: A race condition would occur between ALTER TABLE ... ADD KEY and INSERT statements, resulting in an “Unable to Purge a Record” error.
* InnoDB: A full-text search that returns large result sets would consume an excessive amount of memory due to use of a red-black tree for holding full-text search results. This fix reduces and imposes a limit on memory consumption. If the limit is exceeded, a message is returned indicating that the full-text search query exceeds the maximum allowed memory.
* InnoDB: Restarting InnoDB in read-only mode and running a workload would occasionally return a global_segment < os_aio_n_segments assertion.
* InnoDB: When the InnoDB shutdown mode (innodb_fast_shutdown) is set to 2 and the master thread enters the flush loop, the thread would not be able to exit under some circumstances. This could lead to a shutdown hang.
* InnoDB: While printing a UTF-8 table name, InnoDB would truncate the table name, resulting in an incomplete buffer and subsequent Valgrind error. This bug fix also addresses an incorrect debugging error message.
* InnoDB: Attempting to create a table while in innodb_read_only mode would result in the following error: ERROR 1015 (HY000): Can't lock file (errno: 165 - Table is read only).
* InnoDB: Due to a resource related bug, creating numerous tables that have a simple a full-text search index would cause excessive memory usage. This fix adds a global configuration parameter to limit the total memory size that full-text search indexes can use. If the global memory limit is reached by an index operation, a force sync is triggered.
* InnoDB: In the error log, a full-text search index would be reported missing from the data dictionary during a TRUNCATE TABLE operation. After restarting mysqld, the following InnoDB error would be reported: “InnoDB: Error: trying to load index idx13 for table test/g1 but the index tree has been freed..”
* InnoDB: Creating a table with a comment or default textual value containing an apostrophe that is escaped with a backslash would sometimes cause the InnoDB storage engine to omit foreign key definitions.
* InnoDB: Setting foreign_key_checks=0 and running ALTER TABLE to change the character set of foreign key columns for a database with multiple tables with foreign key constraints would leave the database in an inconsistent state. Subsequent ALTER TABLE operations (using the COPY algorithm) with foreign_key_checks=1 would fail due to the detected inconsistency. Reversion of the partially executed ALTER TABLE operation would also fail, resulting in the loss of the table being altered. When running the same ALTER TABLE operation with a RENAME clause, the inconsistency would not be detected but if the ALTER TABLE operation failed for some other reason, reversion of the partially executed ALTER TABLE would fail with the same result. The bug fix temporarily disables foreign_key_checks while the previous table definition is restored.
* InnoDB: Successive deletes in descending key order would lead to under-filled InnoDB index pages. When an InnoDB index page is under-filled, it is merged with the left or right sibling node. The check performed to determine if a sibling node is available for merging was not functioning correctly.
* InnoDB: The pthread_mutex, commit_threads_m, which was initialized but never used, has been removed from the code base.
* InnoDB: When running an InnoDB full-text search in boolean mode, prefixing an asterisk (*) to a search string ('*string') would result in an error whereas for MyISAM, a prefixed asterisk would be ignored. To ensure compatibility between InnoDB and MyISAM, InnoDB now handles a prefixed asterisk in the same way as MyISAM.
* InnoDB: The row_check_index_for_mysql method, which checks for NULL fields during an index scan or CHECK TABLE operation, would iterate unnecessarily. Thanks to Po-Chun Chang for the patch to correct this issue.
* Partitioning: When upgrading to MySQL 5.5.31 or higher, a message is written into the output of mysql_upgrade when encountering a partitioned table for which the ALGORITHM option is required to maintain binary compatibility with the original; the message includes the ALTER TABLE statement required to make the change. For such a table having a sufficiently large number of partitions, the message was truncated with an error before the complete ALTER TABLE statement could be written.
* Partitioning: When a range specified in the WHERE condition of a query against a table partitioned by RANGE entirely within that of one of the partitions, the next partition was also checked for rows although it should have been pruned away.
* Partitioning: When dropping a partitioned table, the table's .par file was deleted first, before the table definition or data. This meant that, if the server failed during the drop operation, the table could be left in an inconsistent state in which it could neither be accessed nor dropped.
* Replication: The condition leading to the issue fixed continued to raise an error even though the condition itself no longer cause the issue to occur.
* Replication: When rpl_semi_sync_master_timeout was set to an extremely large value, semi-synchronous replication became very slow, especially when many sessions were working in parallel. It was discovered that the code to calculate this timeout was inside the wait loop itself, with the result that an increase in the value of rpl_semi_sync_master_timeout caused repeated iterations. This fix improves the method used to calculate wakeup times, and moves it outside of the wait loop, so that it is executed one time only.
* Replication: It was possible to cause a deadlock after issuing FLUSH TABLES WITH READ LOCK by issuing STOP SLAVE in a new connection to the slave, then issuing SHOW SLAVE STATUS using the original connection.
* The fix for this includes the addition of the rpl_stop_slave_timeout system variable, to control the time in seconds to wait for slave to stop after issuing STOP SLAVE before returning a warning.
* Replication: Some expressions employing variables were not handled correctly by LOAD DATA.
* Replication: In some circumstances, the message in the Last_Error column from the output of SHOW SLAVE STATUS referred to GTID_NEXT_LIST although this variable is not currently implemented (the name is reserved for possible future use). Now in such cases the error message no longer refers to this variable.
* Replication: The error displayed by SHOW SLAVE STATUS when a worker thread fails to apply an event contained no event coordinate information. The GTID for the event's group was also not shown. Now in such cases, the text shown for Last_SQL_Error is prefixed with the (physical) master binary log coordinates, as well as the value of gtid_next when this has been set.
* Replication: Linker errors occurred if the header file log_event.h was included in an application containing multiple source files, because the file rpl_tblmap.cc was included in log_event.h. This fix moves the inclusion of rpl_tblmap.cc into the source files that use log_event.h.
* Replication: The warning issued when specifying MASTER_USER or MASTER_PASSWORD with CHANGE MASTER TO was unclear for a number of reasons, and has been changed to read, Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see 'START SLAVE Syntax' in the MySQL Manual for more information.
* Replication: After a transaction was skipped due to its GTID already having been logged, all remaining executed transactions were incorrectly skipped until gtid_next was pointed to a different GTID.
* Replication: After the client thread on a slave performed a FLUSH TABLES WITH READ LOCK and was followed by some updates on the master, the slave hung when executing SHOW SLAVE STATUS.
* For debug builds, improper use of SAFE_MUTEX within dbug.c caused different code areas to have different ideas about size and contents of a mutex. This could result in out-of-bounds memory writes.
* Sql_condition::set_subclass_origin() could perform an out-of-bounds read.
* Initialization of keycache_* variables (see Multiple Key Caches) during server startup could write to incorrect memory.
* Reads from message buffers for closed connections could occur.
* The server could exit while using a cursor to fetch rows from a UNION query.
* The range optimizer incorrectly assumed that any geometry function on a spatial index returned rows in ROWID order, which could result in incorrect query results.
* The server did excessive locking on the LOCK_active_mi and active_mi->rli->data_lock mutexes for any SHOW STATUS LIKE 'pattern' statement, even when the pattern did not match status variables that use those mutexes (Slave_heartbeat_period, Slave_last_heartbeat, Slave_received_heartbeats, Slave_retried_transactions, Slave_running). Now attempts to show those variables do not lock those mutexes. This might result is slightly stale data, but better performance.
* Full-text phrase search in InnoDB tables could read incorrect memory.
* It was not possible to keep several major versions of MySQL in the same yum repository.
* The Performance Schema could spawn a thread using incorrect instrumentation information.
* INSERT ... ON DUPLICATE KEY UPDATE could cause a server exit if a column with no default value was set to DEFAULT.
* The code base was modified to account for new warning checks introduced by gcc 4.8.
* Compiling failed with -DMY_ATOMIC_MODE_RWLOCKS=1 or on platforms on which MySQL did not support lockless atomic operations (such as ARM).
* In a prepared statement or stored routine, if the HAVING clause of a subquery referenced some column of the GROUP BY of the parent query, the server could exit.
* The read-only open_files_limit system variable did not show maximum number of open files the mysqld process could have, but instead the number that was requested after adjusting the --open-files-limit command-line option.
* Some rows for a session could be missing sporadically from the Performance Schema session_connect_attrs table while the session was executing a workload.
* The server could make the wrong decision about whether an account password was expired.
* Upgrading from community SLES RPM packages to commercial packages for the same MySQL version failed with conflict errors.
* A full-text search syntax error failed to print to standard output.
* Unlike MyISAM, InnoDB does not support boolean full-text searches on nonindexed columns, but this restriction was not enforced, resulting in queries that returned incorrect results.
* If the optimizer was using a loose index scan, the server could exit while attempting to create a temporary table.
* Incorrect results or a server exit could be caused by a reference to an aggregated expression inside a nested subquery, where the aggregated expression was evaluated in a query block more than two levels outer to the reference.
* In debug builds, failure in the range optimizer for an ER_LOCK_DEADLOCK or ER_LOCK_WAIT_TIMEOUT error could go undetected and cause an assertion to be raised when a response was sent to the client. In release builds, this problem manifested as clients receiving an OK for a statement that had failed.
* An assertion could be raised when creating a index on a prefix of a TINYBLOB column in an InnoDB column.
* A server exit could occur for queries of the form SELECT (SELECT 1 FROM t1) IN (SELECT a FROM t1) when attempting to evaluate the constant left-hand argument to the IN subquery predicate.
* No warning was generated if a duplicate index existed after dropping a column associated with a multiple-column index.
* SELECT DISTINCT with WITH ROLLUP could result in a Duplicate entry 'NULL' for key '<auto_key>' error.
* The server could exit in do_copy_not_null() due to an improper NULL-value check.
* Transforming some subqueries that select temporal or BIGINT types or to a semijoin caused a server exit on the second execution of prepared statements or stored programs.
* The usual failed-login attempt accounting was not applied to failed COM_CHANGE_USER commands.
* A user variable referenced during execution of a prepared statement is set to memory that is freed at the end of execution. A second execution of the statement could result in Valgrind warnings when accessing this memory.
* Misoptimization of left expressions in prepared statements could cause a server exit.
* The optimizer trace could print ranges for key parts that were not usable for range access.
* When running a query on INFORMATION_SCHEMA.INNODB_BUFFER_PAGE that requested table_name and index_name values, query results would include index pages without table_name or index_name values.
* Several COM_xxx commands in the client-server protocol did not have length checks for incoming network packets, which could result in various problems for malformed input.
* Passwords in statements were not obfuscated before being written to the audit log.
* With the thread pool plugin in use, normal connection termination caused the Aborted_clients status variable to be incremented.
* On Windows, command-line options of the form --opt_name="opt_value" worked but --opt_name='opt_value' did not.
* On all platforms, for Performance Schema options of the form --performance_schema_instrument="instrument=value", invalid instrument names now are rejected.
* MySQL Installer, if run in custom install or change mode, offered installation options that had no effect.
* Incorrect results could be returned from queries that used several aggr_func(DISTINCT) functions (where aggr_func() is an aggregate function such as COUNT()) when these referred to different columns of the same composite key.
* If an UPDATE containing a subquery caused a deadlock inside InnoDB, the deadlock was not properly handled by the SQL layer. The SQL layer then tried to unlock the row after InnoDB rolled back the transaction, raising an assertion inside InnoDB.
* Boolean plugin system variables did not behave well on machines where char is unsigned; some code attempted to assign a negative value to these.
* In the absence of SQL_CALC_FOUND_ROWS in the preceding query, FOUND_ROWS() should return the number of rows in the result set, but this did not always happen if the query contained ORDER BY.
* Unoptimized versions of the xxxkorr() macros in my_global.h were used on 64-bit x86 processors.
* sql-common/client_plugin.c contained a nonportable use of a va_list parameter.
* mysqldump assumed the existence of the general_log and slow_log tables in the mysql database. It failed if invoked to dump tables from an older server where these tables do not exist.
* Full-text search on InnoDB tables failed on searches for words containing apostrophes.
* Full-text search on InnoDB tables failed on searches for literal phrases combined with + or - operators.
* Optimizations that used extended secondary keys (see Use of Index Extensions) worked only for InnoDB, even for storage engines with the requisite underlying capabilities.
* With big_tables enabled, queries that used COUNT(DISTINCT) on a simple join with a constant equality condition on a non-duplicate key returned incorrect results.
* mysql_install_db incorrectly tried to create the mysql.innodb_table_stats and mysql.innodb_index_stats tables if InnoDB was not available.
* If one session had any metadata lock on a table, another session attempting CREATE TABLE [IF NOT EXISTS] for the same table would hang. This occurred due to an attempt in the second session to acquire an exclusive metadata lock on the table before checking whether the table already existed. An exclusive metadata lock is not compatible with any other metadata locks, so the session hung for the lock timeout period if another session had the table locked. Now the server attempts to acquire a shared metadata lock on the table first to check whether it exists, then upgrade to an exclusive lock if it does not. If the table does exist, an error occurs for CREATE TABLE and a warning for CREATE TABLE IF NOT EXISTS.
* Attempts to build from a source RPM package could fail because the build process attempted to refer to a pb2user that might not exist.
* A typo in cmake/dtrace.cmake prevented DTrace support from being enabled by -DENABLE_DTRACE-on.
* When an internal buffer was too small for the workload, the Performance Schema could spend a lot of time in an internal spin loop attempting to allocate a memory buffer, and fail.
* Some LEFT JOIN queries with GROUP BY could return incorrect results.
* For queries with ORDER BY ... LIMIT, the optimizer could choose a nonordering index for table access.
* When selecting a union of an empty result set (created with WHERE 1=0 or WHERE FALSE) with a derived table, incorrect filtering was applied to the derived table.
* Comparison of a DATETIME value and a string did not work correctly for the utf8_unicode_ci collation.

# Functionality Added or Changed
* Previously, program options could be specified in full or as any unambiguous prefix. For example, the --compress option could be given to mysqldump as --compr, but not as --comp because the latter is ambiguous. Option prefixes now are deprecated. They can cause problems when new options are implemented for programs. A prefix that is currently unambiguous might become ambiguous in the future. If an unambiguous prefix is given, a warning now occurs to provide feedback. For example: Warning: Using unique option prefix compr instead of compress is deprecated and will be removed in a future release. Please use the full name instead. Option prefixes are no longer supported in MySQL 5.7; only full options are accepted.
* comp_err now checks to make sure that new errors are not being added to MySQL 5.1 or 5.5 because the set of errors for these series is frozen.
# Bugs Fixed
* Performance; Important Change; InnoDB: InnoDB would fail to open a tablespace that has multiple data files. This removes the known limitation that was in MySQL Server 5.6.12.
* Performance; InnoDB: When innodb_thread_concurrency is set to a non-zero value, there was a possibility that all innodb_concurrency_tickets would be released after each row was read, resulting in a concurrency check after each read. This could impact performance of all queries. One symptom could be higher system CPU usage. We strongly recommend that you upgrade to MySQL Server 5.6.13 if you use this setting. This could cause a performance drop between MySQL Server 5.5.x and 5.6.x.
* MySQL Cluster: CREATE LOGFILE GROUP failed with a syntax error when INITIAL_SIZE, UNDO_BUFFER_SIZE, or both options were specified.
* InnoDB: When CHECK TABLE found a secondary index that contained the wrong number of entries, it would report an error but not mark the index as corrupt. CHECK TABLE now marks the index as corrupt when this error is encountered, but only the index is marked as corrupt, not the table. As a result, only the index becomes unusable until it is dropped and rebuilt. The table is unaffected.
* InnoDB: InnoDB would attempt to gather statistics on partially created indexes.
* InnoDB: The two INFORMATION_SCHEMA tables for the InnoDB buffer pool could show an invalid page type for read-fixed blocks. This fix will show the unknown page type for blocks that are I/O-fixed for reading.
* InnoDB: During an insert buffer merge, InnoDB would invoke lock_rec_restore_from_page_infimum() on a potentially invalid record pointer.
* InnoDB: The page_zip_validate() consistency check would fail after compressing a page, in page_zip_compress(). This problem was caused by page_zip_decompress(), which would fail to set heap_no correctly when a record contained no user data bytes. A record with no user data bytes occurs when, for example, a primary key is an empty string and all secondary index fields are NULL or an empty string.
* InnoDB: During a transaction commit, prepare_commit_mutex is acquired to preserve the commit order. If the commit operation failed, the transaction would be rolled back but the mutex would not be released. Subsequent insert operations would not be able to acquire the same mutex. This fix frees prepare_commit_mutex during innobase_rollback.
* InnoDB: When the InnoDB shutdown mode (innodb_fast_shutdown) is set to 2 and the master thread enters the flush loop, the thread would not be able to exit under some circumstances. This could lead to a shutdown hang.
* InnoDB: After disabling foreign key checks with SET foreign_key_checks=0 and performing a DROP INDEX, the table was no longer accessible after restarting the server. This fix allows the table with missing foreign key indexes to be accessed when SET foreign_key_checks=0. When the table is accessible, the user must recreate the missing indexes to fulfill the foreign key constraints.
* InnoDB: Creating a table with a comment or default textual value containing an apostrophe that is escaped with a backslash would sometimes cause the InnoDB storage engine to omit foreign key definitions.
* InnoDB: Setting foreign_key_checks=0 and running ALTER TABLE to change the character set of foreign key columns for a database with multiple tables with foreign key constraints would leave the database in an inconsistent state. Subsequent ALTER TABLE operations (using the COPY algorithm) with foreign_key_checks=1 would fail due to the detected inconsistency. Reversion of the partially executed ALTER TABLE operation would also fail, resulting in the loss of the table being altered. When running the same ALTER TABLE operation with a RENAME clause, the inconsistency would not be detected but if the ALTER TABLE operation failed for some other reason, reversion of the partially executed ALTER TABLE would fail with the same result.
* The bug fix temporarily disables foreign_key_checks while the previous table definition is restored.
* InnoDB: Successive deletes in descending key order would lead to under-filled InnoDB index pages. When an InnoDB index page is under-filled, it is merged with the left or right sibling node. The check performed to determine if a sibling node is available for merging was not functioning correctly.
* InnoDB: The pthread_mutex, commit_threads_m, which was initialized but never used, has been removed from the code base.
* Partitioning: When upgrading to MySQL 5.5.31 or higher, a message is written into the output of mysql_upgrade when encountering a partitioned table for which the ALGORITHM option is required to maintain binary compatibility with the original; the message includes the ALTER TABLE statement required to make the change. For such a table having a sufficiently large number of partitions, the message was truncated with an error before the complete ALTER TABLE statement could be written.
* Partitioning: When a range specified in the WHERE condition of a query against a table partitioned by RANGE entirely within that of one of the partitions, the next partition was also checked for rows although it should have been pruned away.
* Partitioning: When dropping a partitioned table, the table's .par file was deleted first, before the table definition or data. This meant that, if the server failed during the drop operation, the table could be left in an inconsistent state in which it could neither be accessed nor dropped.
* Replication: Some expressions employing variables were not handled correctly by LOAD DATA.
* Replication: Linker errors occurred if the header file log_event.h was included in an application containing multiple source files, because the file rpl_tblmap.cc was included in log_event.h. This fix moves the inclusion of rpl_tblmap.cc into the source files that use log_event.h.
* Installation of Solaris PKG packages could fail to execute mysql_install_db because it was invoked with the --random-passwords option (which does not exist until MySQL 5.6).
* Initialization of keycache_* variables (see Multiple Key Caches) during server startup could write to incorrect memory.
* Removing a server RPM package did not shut down the existing server if it was running.
* The code base was modified to account for new warning checks introduced by gcc 4.8.
* Upgrading from community SLES RPM packages to commercial packages for the same MySQL version failed with conflict errors.
* A user variable referenced during execution of a prepared statement is set to memory that is freed at the end of execution. A second execution of the statement could result in Valgrind warnings when accessing this memory.
* Misoptimization of left expressions in prepared statements could cause a server exit.
* Out-of-bounds reads could occur within filename_to_tablename().
* When running a query on INFORMATION_SCHEMA.INNODB_BUFFER_PAGE that requested table_name and index_name values, query results would include index pages without table_name or index_name values.
* With the thread pool plugin in use, normal connection termination caused the Aborted_clients status variable to be incremented.
* MySQL Installer, if run in custom install or change mode, offered installation options that had no effect.
* Incorrect results could be returned from queries that used several aggr_func(DISTINCT) functions (where aggr_func() is an aggregate function such as COUNT()) when these referred to different columns of the same composite key.
* Assigning the result of a subquery to a user variable raised an assertion when the outer query included DISTINCT and GROUP BY.
* mysqldump assumed the existence of the general_log and slow_log tables in the mysql database. It failed if invoked to dump tables from an older server where these tables do not exist.
* Attempts to build from a source RPM package could fail because the build process attempted to refer to a pb2user that might not exist.
* A typo in cmake/dtrace.cmake prevented DTrace support from being enabled by -DENABLE_DTRACE-on.
* RPM source packages did not list libaio-devel as a dependency, causing builds to fail.
* Comparison of a DATETIME value and a string did not work correctly for the utf8_unicode_ci collation.

# Functionality Added or Changed
- mysql_upgrade now verifies that the server version matches the version against which it was compiled, and exits if there is a mismatch. In addiion, a --version-check option permits specifying whether to enable version checking (the default), or disable checking if given as --skip-version-checking.
# Bugs Fixed
- Incompatible Change: When used for an existing MySQL account, the GRANT statement could produce unexpected reults if it included an IDENTIFIED WITH clause that named an authentication plug differing from the plugin named in the corresponding mysql.user table row. Because IDENTIFIED WITH is intended for GRANT statements that create a new user, it is now prohibited if the named account already exists.
- Important Change; Replication: When the server was running with --binlog-ignore-db and SELECT DATABASE() returned NULL (that is, there was no currently selected database), statements using fully qualified table names in dbname.tblname format were not written to the binary log. This was because the lack of a currently selected database in such cases was treated as a match for any possible ignore option rather than for no such option; this meant that these statements were always ignored. Now, if there is no current database, a statement using fully qualified table names is always written to the binary log.
- InnoDB; Partitioning: Joins involving partitioned InnoDB tables having one or more BLOB columns were not always handled correctly. The BLOB column or columns were not required to be join columns, or otherwise to be named or referenced in the statement containing the join, for this issue to occur.
- InnoDB: In debug builds, an online ALTER TABLE operation that performed a full table copy would raise an assertion. The assertion was due to a race condition that would occur during BLOB retrieval, when applying the table modification log to any log block except for the very last one. This fix modifies row_log_table_apply_convert_mrec() to ensure that an index B-tree lock is acquired to protect the access to log->blobs and the BLOB page.
- InnoDB: When the function trx_rollback_or_clean_recovered() rolls back or cleans up transactions during a crash recovery, it removes the trx objects from the trx_sys list without freeing up the memory used by those objects. To prevent a memory leak, this fix adds trx_free_for_background() calls to trx_rollback_resurrected(), the function that removes the trx objects.
- InnoDB: A missing comma in SHOW STATUS output would break MySQL Enterprise Monitor parsing.
- InnoDB: After a clean shutdown, InnoDB does not check .ibd file headers at startup. As a result, in a crash recovery scenario, InnoDB could load a corrupted tablespace file. This fix implements consistency and status checks to avoid loading corrupted files.
- InnoDB: A memory leak would occur in dict_check_tablespaces_and_store_max_id() when space_id is equal to zero.
- 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: DML operations on compressed temporary tables would result in a Valgrind error in the buffer manager stack.
- InnoDB: This fix addresses a race condition that would occur between the rollback of a recovered transaction and creation of a secondary index in a locked operation. The race condition would corrupt the secondary index.
- 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: Under certain circumstances, LRU flushing would take a long time possibly affecting all flushing activity and causing a shutdown timeout.
- InnoDB: The recv_writer thread would only start after all redo log scans finished. In the case of multiple redo log scans, accumulated redo records would be applied after each scan and before processing the next scan. The absence of the recv_writer thread to help with flushing would slow recovery or result in a server startup timeout. This fix ensures that the recv_writer thread starts before the first scan batch is processed.
- InnoDB: This fix replaces the IB_ULONGLONG_MAX constant with LSN_MAX where the code refers to log sequence numbers, or with TRX_ID_MAX where trx->no is initialized to an undefined value. This change does not alter the value of the constant.
- InnoDB: This fix corrects the text for InnoDB error 6025, which stated, “InnoDB: read can't be opened in ./ib_logfile0 mode.”. The corrected message states, “InnoDB: ./ib_logfile0 can't be opened in read mode.” The variable and mode in the message construct were transposed.
- InnoDB: The page_zip_available function would count some fields twice.
- InnoDB: This fix removes most calls to OS_THREAD_SLEEP from InnoDB.
- InnoDB: Concurrently inserting into a full-text table would cause some inserts to fail. Duplicate values would be generated for full-text search document IDs when performing inserts into a hidden full-text search document ID column.
- InnoDB: FLUSH TABLES FOR EXPORT would sleep too often while flushing pages from buffer pools.
- InnoDB: In cases where threads are forced to do single page flushing, fsync() would be triggered for all data files. This fix allows for synchronous single page flushing.
- InnoDB: In debug builds, an insert would fail with an invalid assertion: sync_thread_levels_g(array, level - 1, TRUE).
- InnoDB: Multiple concurrent calls to dict_update_statistics() would result in unnecessary server load.
- InnoDB: On 64-bit Windows builds, INNODB_BUFFER_POOL_SIZE would not accept an allocation of more than 32GB. This limitation was due to a bug that truncated the internal value for the InnoDB buffer pool size to 32 bits on 64-bit Windows builds.
- InnoDB: Crash recovery would fail with a !recv_no_log_write assertion when reading a page.
- InnoDB: Creating a foreign key constraint using the ALTER TABLE INPLACE algorithm requires foreign_key_checks to be set to 0 (SET foreign_key_checks = 0;). As a result, an appropriate duplicate ID check would not be performed.
- InnoDB: RENAME TABLE would result in a hang due to a MySQL mutex acquisition deadlock. (
- InnoDB: DROP DATABASE failed if the database contained an InnoDB table that had a data file in an external data directory. The external data file had an “InnoDB Symbolic Link” file type (.isl) that was not recognized by MySQL. This fix adds .isl as a known InnoDB file type.
- InnoDB: When tables are linked by foreign key constraints, loading one table would open other linked tables recursively. When numerous tables are linked by foreign key constraints, this would sometimes lead to a thread stack overflow causing the server to exit. Tables linked by foreign key constraints are now loaded iteratively. Cascade operations, which were also performed in a recursive manner, are now performed iteratively using an explicit stack.
- InnoDB: When calling the lock_rec_block_validate() function after releasing the kernel mutex, there is a chance the lock might be invalid and result in a Valgrind error due to an invalid read on lock->index. This fix copies the lock->index when the kernel mutex is being held and passes the lock->index to lock_rec_block_validate().
- InnoDB: Under testing, a FLUSH TABLE operation resulted in a timeout due to a missing acknowledgement that the purge thread had stopped.
- InnoDB: For a compressed table, the “page reorganize” function would ignore the innodb_log_compressed_pages option and always log the entire compressed page, which increased the size of the redo log. The “page reorganize” function now adheres to the innodb_log_compressed_pages option and does not log compressed page images to the redo log when innodb_log_compressed_pages is set to “OFF”.
- InnoDB: After disabling foreign key checks with SET foreign_key_checks=0 and performing a DROP INDEX, the table was no longer accessible after restarting the server. This fix allows the table with missing foreign key indexes to be accessed when SET foreign_key_checks=0. When the table is accessible, the user must recreate the missing indexes to fulfill the foreign key constraints.
- InnoDB: When a transaction is in READ COMMITTED isolation level, gap locks are still taken in the secondary index when a row is inserted. This occurs when the secondary index is scanned for duplicates. The function row_ins_scan_sec_index_for_duplicate() always calls the function row_ins_set_shared_rec_lock() with LOCK_ORDINARY irrespective of the transaction isolation level. This fix modifies the row_ins_scan_sec_index_for_duplicate() function to call row_ins_set_shared_rec_lock() with LOCK_ORDINARY or LOCK_REC_NOT_GAP, based on the transaction isolation level.
- InnoDB: Starting mysqld with --innodb_log_buffer_size=50GB failed to allocate memory and returned NULL. For non-debug builds there was no check in place and a segmentation fault occurred. This fix adds a log message stating that memory failed to be allocated, and adds an assertion.
- InnoDB: When UNIV_DEBUG is enabled in debug builds, buf_validate() is often called which sometimes results in false alarms in tests on semaphore wait timeout. This fix increases counter values to reduce false alarms.
- InnoDB: While processing read-write workloads, InnoDB would scan more pages than are required for flushing, unnecessarily consuming CPU resource.
- InnoDB: The explain_filename function, which provides information about a partition by parsing the file name, would return an error when attempting to parse a file name with no partition information.
- InnoDB: Stopping the server, removing a database table (d1.t1) .frm file from the data directory, restarting the server, and dropping the database (d1), would cause an assertion.
- InnoDB: An active FLUSH TABLE FOR EXPORT thread would cause a hang during shutdown. The fix ensures that trx_is_interrupted() is checked during ibuf_merge.
- InnoDB: A multi-row INSERT ... ON DUPLICATE KEY UPDATE insert failure, caused by a duplicate key error, would result in duplicate auto-increment values.
- Replication: Point-in-time recovery could fail when trying to restore a single database from a binary log in row-based format using mysqlbinlog with the --database option.
- Replication: Issuing a FLUSH TABLES statement on a GTID-enabled master caused replication to fail. It was found that this misbehavior was introduced by the fix for Bug #16062608, which disallowed statements that perform an implicit commit but whose changes are not logged when gtid_next is set to any value other than AUTOMATIC. The changes made in that fix have been reverted, and such statements are (again) allowed without regard to the value of this variable.
- Replication: A crash-on-commit error caused InnoDB to lose the previous transaction following execution of a RESET MASTER statement. This occurred because the prepare phase caused a flush to disk, while the commit phase did not perform a corresponding flush within InnoDB. To fix this problem, RESET MASTER now causes storage engine logs to be flushed on commit.
- Replication: When used with the options --dump-slave --include-master-host-port, mysqldump printed the port number within quotation marks, as if it were a string value rather than an integer.
- Replication: When processing an Update_rows_log_event or Delete_rows_log_event from the binary log, the before image is hashed and stored in a hash table. Following this, the original table is scanned for the desired records; subsequent processing hashes each record fetched from the original table and performs a lookup for it in the hash table. However, columns read from the image that had originally been set to NULL could instead contain random or “garbage” data, causing the lookup (and thus replication) to fail with an error such as Could not execute Update_rows event on table....
- Replication: Due to time resolution issues on some systems, the time to be taken by the dump thread for a reply from the slave could be calculated to be less than zero, leading to Semi-sync master wait for reply fail to get wait time errors. Since this condition does not have a negative impact on replication, errors caused by these conditions have been reduced to warnings.
- Replication: When one or more GTID log events but no previous GTIDs log events were found in the binary log, the resulting error was mishandled and led to a failure of the server. (This is an extremely rare condition that should never occur under normal circumstances, and likely indicates that the binary log file has somehow been corrupted.) Now in such cases, an appropriate error is issued, and is handled correctly.
- Replication: Running the server with both the --log-slave-updates and --replicate-wild-ignore-table options in some cases caused updates to user variables not to be logged.
- Replication: When using mysqlbinlog and the mysql client to roll forward two or more binary logs on a server having GTIDs enabled, the gtid_next variable was not properly reset when switching from the first to the second binary log, causing processing to halt with an error at that point.
- Replication: The mysqlbinlog options --include-gtids, --exclude-gtids, and --skip-gtids did not work correctly when trying to process multiple files.
- Replication: When the size of an execution event exceeded the maximum set for the buffer (slave_pending_jobs_size_max), row-based replication could hang with Waiting for slave workers to free pending events.
- Replication: Extra binary log rotations were performed due to concurrent attempts at rotation when the binary log became full, which were allowed to succeed. This could lead to the unnecessary creation of many small binary log files.
- Replication: Attempting to execute START SLAVE after importing new slave_master_info and slave_relay_log_info tables failed with an empty error message. Now an appropriate error and message are issued in such cases.
- Replication: Restarting the server after the slave_relay_log_info table had been emptied caused mysqld to fail while trying to return an error.
- Replication: Following disconnection from the master, the slave could under certain conditions report erroneously on reconnection that it had received a packet that was larger than slave_max_allowed_packet, causing replication to fail.
- Replication: An SQL thread error during MTS slave recovery caused the slave to fail.
- Replication: When using the options --read-from-remote-server --stop-never --base64-output=decode-rows --verbose, mysqlbinlog failed to reset the counter used to store the current position within the file when the binary log on the server was rotated.
- Replication: When using mysqldump to back up a database created with MySQL 5.6.4 or an earlier version, setting --set-gtid-purged=AUTO caused the backup to fail, because pre-5.6.5 versions of MySQL did not support GTIDs, and it could not be determined if GTIDs were enabled for the database. This fix makes sure mysqldump does not attempt to output a SET @@global.gtid_purged statement when backing up any pre-5.6.5 databases.
- Replication: Deadlocks could sometimes occur on group commits with a high number of concurrent updates, as well as when one client held a lock from a commit while another client imposed a lock while rotating the binary log.
- Replication: When semisynchronous replication was enabled, the automatic dropping on the master of an event created using ON COMPLETION NOT PRESERVE caused the master to fail.
- Replication: Setting a SET column to NULL inside a stored procedure caused replication to fail.
- Replication: The binary log contents got corrupted sometimes, because the function MYSQL_BIN_LOG::write_cache always thought it had reached the end-of-cache when the function my_b_fill() reported a '0,' while that could also mean an error had occurred. This fix makes sure that whenever my_b_fill() returns a '0,' an error check is performed on info->error.
- Replication: PURGE BINARY LOGS by design does not remove binary log files that are in use or active, but did not provide any notice when this occurred. Now, when log files are not removed under such conditions, a warning is issued; this warning includes information about the file or files were not removed when the statement was issued.
- Replication: When replicating to a BLACKHOLE table using the binary logging format, updates and deletes cannot be applied and so are skipped. Now a warning is generated for this whenever it occurs. Note: binlog_format=STATEMENT is recommended when replicating to tables that use the BLACKHOLE storage engine.
- Removing a server RPM package did not shut down the existing server if it was running.
- Overhead for setting PROCESSLIST_STATE values in the Performance Schema THREADS table has been reduced.
- The Windows authentication plugin failed to free a context buffer for each connection.
- The DBUG_PRINT() macro unnecessarily evaluated arguments when debugging was not enabled.
- When index condition pushdown was used on a descending range scan and the first range interval did not contain any qualifying records, the result of the range scan could be empty even if other range intervals contained qualifying records.
- The server could attempt a filesort operation for a zero-size sort length, causing it to exit.
- my_load_defaults() was modified to accommodate some problems under compilation with gcc 4.7.2 that could cause a client crash during option processing.
- Opening a cursor on a SELECT within a stored procedure could cause a segmentation fault.
- SET PASSWORD treated user@'%' and user@'' as referring to the same mysql.user table row.
- Geometry methods that worked with WKB data performed insufficient input data validation, which could cause Valgrind errors or a server exit.
- Some INFORMATION_SCHEMA queries that used ORDER BY did not use a filesort optimization as they did in MySQL 5.5.
- Performance Schema parameter autosizing at startup did not take into account later autosizing changes to other startup parameters on which the Performance Schema parameters depended.
- The WKB reader for spatial operations could fail and cause a server exit.
- Optimizer heuristics inappropriately preferred range access over ref access in cases when the ref access referred to a column of a table earlier in the join
- Manually-created accounts (using INSERT) with a malformed password effectively had no password.
- Several scripts in the sql-bench directory that were supposed to be executable did not have the executable access bit set.
- For debug builds, DBUG_EXPLAIN resulted in a buffer overflow when the debug system variable value was more than 255 characters.
- Within an XA transaction in ACTIVE state, statements causing an implicit commit could result in metadata locks being released too early.
- Installing Debian packages on Ubuntu 12.10 succeeded using dpkg, but not with Software Center 5.4.1.4.
- For debug builds, with an XA transaction in IDLE or PREPARED status, execution of a query with the query cache enabled could cause a server exit.
- thread_pool_high_priority_connection could not be set at server startup.
- Re-execution of a stored procedure could cause a server exit in Item_field::fix_outer_field.
- A GROUP_CONCAT() invocation containing subquery having an outer reference caused the server to exit.
- With secure_auth enabled, a user with a password that used the pre-4.1 (old) hashing could not update it to use the 4.1 (new) hashing.
- For debug builds, GROUP_CONCAT(... ORDER BY) within an ORDER BY clause could cause a server exit.
- The validate_password plugin did not always enforce appropriate constraints against assigning empty passwords.
- For debug builds, the server could exit for queries involving a nested subquery, a subquery tranformed into a semi-join and using a view.
- The range optimizer could set up incorrect ranges for queries that used XOR operations.
- mysql_secure_installation could not connect to the server if the account used had an expired password. It invoked mysql noninteractively, resulting in that program failing to connect. Now mysql supports a --connect-expired-password option that indicates to the server that it can handle sandbox mode for expired-password accounts even if invoked noninteractively, and mysql_secure_installation invokes mysql with this option.
- If loose index scan was used on a query that used MIN(), a segmentation fault could occur.
- If multiple statements were sent in a single request, the audit log plugin logged only the last one. Now it logs each statement separately.
- For debug builds, an assertion was incorrectly raised for queries executed using eq_ref access and filesort.
- An outer join between a regular table and a derived table that is implicitly groups could cause a server exit.
- A prepared statement that used GROUP_CONCAT() and an ORDER BY clause that named multiple columns could cause the server to exit.
- Creating a FEDERATED table without specifying a connection string caused a server exit.
- ORDER BY MATCH ... AGAINST could cause a server exit.
- Client programs from MySQL 5.6.4 and up could confuse older servers during the connection process by using newer protocol features not understood by older servers.
- When a partition is missing, code in ha_innodb.cc would retry 10 times and sleep for a microsecond each time while holding LOCK_open. The retry logic for partitioned tables was introduced as a fix but did not include a test case to validate it. This fix removes the retry logic for partitioned tables. If the problem reported reappears, a different solution will be explored.
- The mysql.server script exited with an error if the status command was executed with multiple servers running.
- Use of the VALUES() function in the VALUES() clause of an INSERT statement could result in Valgrind warnings or an unstable server, possibly leading to a server exit.
- In some cases, REVOKE could fail to revoke the GRANT OPTION privilege.
- The mysql client allocated but did not free a string after reading each line in interactive mode, resulting in a memory leak.
- Killing a connection while it was in the process of disconnecting could lead to an assertion being raised, Valgrind warnings, and general unstability.
- INSERT ... ON DUPLICATE KEY UPDATE on a view could cause a server exit.
- Grouping by an outer BLOB column in a subquery caused a server exit.
- The server could exit due to improper handling of the error from an invalid comparison.
- The CMake check for unsigned time_t failed on all platforms.
- mysqladmin debug causes the server to write debug information to the error log. On systems that supported mallinfo(), the memory-status part of this output was incorrect in 64-bit environments when mysqld consumed more than 4GB memory.
Now the server uses malloc_info() to obtain memory-status information. malloc_info() does not report the memory that the glibc malloc() implementation internally allocates using mmap(). However, it does provide the memory usage information in all the memory arenas.
This bug fix also involves a change of output format. The server now writes memory information in XML format rather than as plain text. Example:
Memory status:
<malloc version="1">
<heap nr="0">
<sizes>
<size from="33" to="33" total="1056" count="32"/>
<size from="65" to="65" total="65" count="1"/>
<size from="113" to="113" total="226" count="2"/>
<size from="129" to="129" total="2451" count="19"/>
<size from="145" to="145" total="290" count="2"/>
<size from="161" to="161" total="1288" count="8"/>
<size from="209" to="209" total="418" count="2"/>
</sizes>
<total type="fast" count="0" size="0"/>
<total type="rest" count="66" size="5794"/>
<system type="current" size="10833920"/>
<system type="max" size="10833920"/>
<aspace type="total" size="10833920"/>
<aspace type="mprotect" size="10833920"/>
</heap>
<total type="fast" count="0" size="0"/>
<total type="rest" count="66" size="5794"/>
<system type="current" size="10833920"/>
<system type="max" size="10833920"/>
<aspace type="total" size="10833920"/>
<aspace type="mprotect" size="10833920"/>
</malloc>
- On 64-bit Mac OS X systems, CMake used x86 rather than x86_64 when determining the machine type.
- The mysql client incorrectly used latin1 for certain comparisons even if started with a multibyte default character set, resulting in a client crash.
- The url columns in the mysql datatbase help tables were too short to hold some of the URLs in the help content. These columns are now created as type TEXT to accommodate longer URLs.
- mysqld --help and mysqld --verbose --help performed unnecessary logging.
- InnoDB does not support full-text parser plugins, but failed to report an error if they were specified. Now an ER_INNODB_NO_FT_USES_PARSER error is returned.
- If Loose Index Scan was used to evaluate a query that compared an integer column to an integer specified as a quoted string (for example, col_name = '1'), the query could return incorrect results.
- IF() function evaluations could produce different results when executed in a prepared versus nonprepared statement.
- If a function such as AES_DECRYPT() that requires SSL support failed, the error could affect later calls to functions that require SSL support.
- In a MySQL server newer than MySQL 5.5 using a nonupgraded mysql.user table (for which mysql_upgrade had not been run), statements to set passwords caused a server exit due to a faulty check for the password_expired column.
- It is now possible to suppress installation of the mysql-test directory after compiling MySQL from source by invoking CMake with the INSTALL_MYSQLTESTDIR option explicitly set to empty: cmake . -DINSTALL_MYSQLTESTDIR= Previously, attempts to do this resulted in an error.
- When only counting events but not timing them, Performance Schema would report MIN_TIMER_WAIT values as a large number instead of 0.
- Using range access with an index prefix could produce incorrect results.
- For debug builds, metadata locking for CREATE TABLE ... SELECT could raise an assertion.
- A new CMake option, WITH_EDITLINE, is provided to indicate whether to use the bundled or system libedit/editline library. The permitted values are bundled (the default) and system. WITH_EDITLINE replaces WITH_LIBEDIT, which has been removed.
- When specified in an option file, the plugin-dir client option was ignored.
- Indexes on derived tables that were used during the first invocation of a stored procedure were not used in subsequent invocations.
- For DELETE and UPDATE statements, EXPLAIN displayed NULL in the ref column for some cases where const is more appropriate.
- The optimizer could choose a poor execution plan for queries with ORDER BY ... LIMIT.
- FOUND_ROWS() could return an incorrect value if the preceding query used filesort.

# Functionality Added or Changed
- mysql_upgrade now verifies that the server version matches the version against which it was compiled, and exits if there is a mismatch. In addiion, a --version-check option permits specifying whether to enable version checking (the default), or disable checking if given as --skip-version-checking.
# Bugs Fixed
- Important Change; Replication: When the server was running with --binlog-ignore-db and SELECT DATABASE() returned NULL (that is, there was no currently selected database), statements using fully qualified table names in dbname.tblname format were not written to the binary log. This was because the lack of a currently selected database in such cases was treated as a match for any possible ignore option rather than for no such option; this meant that these statements were always ignored. Now, if there is no current database, a statement using fully qualified table names is always written to the binary log.
- InnoDB: After a clean shutdown, InnoDB does not check .ibd file headers at startup. As a result, in a crash recovery scenario, InnoDB could load a corrupted tablespace file. This fix implements consistency and status checks to avoid loading corrupted files.
- InnoDB: The page_zip_available function would count some fields twice.
- InnoDB: In debug builds, an insert would fail with an invalid assertion: sync_thread_levels_g(array, level - 1, TRUE).
- InnoDB: Multiple concurrent calls to dict_update_statistics() would result in unnecessary server load.
- InnoDB: Crash recovery would fail with a !recv_no_log_write assertion when reading a page.
- InnoDB: When calling the lock_rec_block_validate() function after releasing the kernel mutex, there is a chance the lock might be invalid and result in a Valgrind error due to an invalid read on lock->index. This fix copies the lock->index when the kernel mutex is being held and passes the lock->index to lock_rec_block_validate().
- InnoDB: When a transaction is in READ COMMITTED isolation level, gap locks are still taken in the secondary index when a row is inserted. This occurs when the secondary index is scanned for duplicates. The function row_ins_scan_sec_index_for_duplicate() always calls the function row_ins_set_shared_rec_lock() with LOCK_ORDINARY irrespective of the transaction isolation level. This fix modifies the row_ins_scan_sec_index_for_duplicate() function to call row_ins_set_shared_rec_lock() with LOCK_ORDINARY or LOCK_REC_NOT_GAP, based on the transaction isolation level.
- InnoDB: Starting mysqld with --innodb_log_buffer_size=50GB failed to allocate memory and returned NULL. For non-debug builds there was no check in place and a segmentation fault occurred. This fix adds a log message stating that memory failed to be allocated, and adds an assertion.
- InnoDB: When UNIV_DEBUG is enabled in debug builds, buf_validate() is often called which sometimes results in false alarms in tests on semaphore wait timeout. This fix increases counter values to reduce false alarms.
- InnoDB: The explain_filename function, which provides information about a partition by parsing the file name, would return an error when attempting to parse a file name with no partition information.
- InnoDB: For UPDATE statements in which an error occurred, it was possible for a temporary file opened during the update not to be closed.
- InnoDB: An overflow would occur for innodb_row_lock_time_max and innodb_row_lock_current_waits. This fix modifies code logic in storage/innobase/srv/srv0srv.c.
- Replication: Point-in-time recovery could fail when trying to restore a single database from a binary log in row-based format using mysqlbinlog with the --database option.
- Replication: When used with the options --dump-slave --include-master-host-port, mysqldump printed the port number within quotation marks, as if it were a string value rather than an integer.
- Replication: Running the server with both the --log-slave-updates and --replicate-wild-ignore-table options in some cases caused updates to user variables not to be logged.
- Replication: Following disconnection from the master, the slave could under certain conditions report erroneously on reconnection that it had received a packet that was larger than slave_max_allowed_packet, causing replication to fail.
- Replication: When semisynchronous replication was enabled, the automatic dropping on the master of an event created using ON COMPLETION NOT PRESERVE caused the master to fail.
- Replication: Setting a SET column to NULL inside a stored procedure caused replication to fail.
- Replication: The binary log contents got corrupted sometimes, because the function MYSQL_BIN_LOG::write_cache always thought it had reached the end-of-cache when the function my_b_fill() reported a '0,' while that could also mean an error had occurred. This fix makes sure that whenever my_b_fill() returns a '0,' an error check is performed on info->error.
- Replication: When replicating to a BLACKHOLE table using the binary logging format, updates and deletes cannot be applied and so are skipped. Now a warning is generated for this whenever it occurs. Note : binlog_format=STATEMENT is recommended when replicating to tables that use the BLACKHOLE storage engine.
- The WKB reader for spatial operations could fail and cause a server exit.
- EXPORT_SET() or MAKE_SET() with many COUNT(*) arguments could cause a server exit.
- Several scripts in the sql-bench directory that were supposed to be executable did not have the executable access bit set.
- For debug builds, DBUG_EXPLAIN resulted in a buffer overflow when the debug system variable value was more than 255 characters.
- thread_pool_high_priority_connection could not be set at server startup.
- Oracle RPM packages were unusable by yum due to issues with the obsoletes line in the .spec file causing yum to interpret the package as obsoleting itself.
- A GROUP_CONCAT() invocation containing subquery having an outer reference caused the server to exit.
- For debug builds, GROUP_CONCAT(... ORDER BY) within an ORDER BY clause could cause a server exit.
- If loose index scan was used on a query that used MIN(), a segmentation fault could occur.
- If multiple statements were sent in a single request, the audit log plugin logged only the last one. Now it logs each statement separately.
- A prepared statement that used GROUP_CONCAT() and an ORDER BY clause that named multiple columns could cause the server to exit.
- ORDER BY MATCH ... AGAINST could cause a server exit.
- When a partition is missing, code in ha_innodb.cc would retry 10 times and sleep for a microsecond each time while holding LOCK_open. The retry logic for partitioned tables was introduced as a fix but did not include a test case to validate it. This fix removes the retry logic for partitioned tables. If the problem reported reappears, a different solution will be explored.
- The mysql.server script exited with an error if the status command was executed with multiple servers running.
- A query with a union and a join could crash the parser.
- Installation using Solaris packages ran mysql_install_db during upgrade operations (this should occur only for new installations).
- When processing row-based-replication events in the old binary log format from prior to MySQL 5.1 GA builds, mysqlbinlog could result in out-of-bounds heap buffer reads and undefined behaviour.
- The mysql client allocated but did not free a string after reading each line in interactive mode, resulting in a memory leak.
- INSERT ... ON DUPLICATE KEY UPDATE on a view could cause a server exit.
- Grouping by an outer BLOB column in a subquery caused a server exit.
- The server could exit due to improper handling of the error from an invalid comparison.
- The CMake check for unsigned time_t failed on all platforms.
- On 64-bit Mac OS X systems, CMake used x86 rather than x86_64 when determining the machine type.
- The parser rejected legal queries that involved a UNION where the right hand side query term has a table in parenthese.
- The url columns in the mysql datatbase help tables were too short to hold some of the URLs in the help content. For new installations, these columns are now created as type TEXT to accommodate longer URLs. For upgrades, mysql_upgrade does not update the columns. Modify them manually using these statements:
ALTER TABLE mysql.help_category MODIFY url TEXT NOT NULL;
ALTER TABLE mysql.help_topic MODIFY url TEXT NOT NULL;
- If Loose Index Scan was used to evaluate a query that compared an integer column to an integer specified as a quoted string (for example, col_name = '1'), the query could return incorrect results.
- IF() function evaluations could produce different results when executed in a prepared versus nonprepared statement.
- It is now possible to suppress installation of the mysql-test directory after compiling MySQL from source by invoking CMake with the INSTALL_MYSQLTESTDIR option explicitly set to empty: cmake . -DINSTALL_MYSQLTESTDIR= Previously, attempts to do this resulted in an error.
- Using range access with an index prefix could produce incorrect results.
- MD5() code did not properly initialize one of its data structures.
- When specified in an option file, the plugin-dir client option was ignored.
- If an UPDATE containing a subquery caused a deadlock inside InnoDB, the deadlock was not properly handled by the SQL layer. The SQL layer then tried to unlock the row after InnoDB rolled back the transaction, raising an assertion inside InnoDB.

# Bugs Fixed
- Important Change; Replication: When the server was running with --binlog-ignore-db and SELECT DATABASE() returned NULL (that is, there was no currently selected database), statements using fully qualified table names in dbname.tblname format were not written to the binary log. This was because the lack of a currently selected database in such cases was treated as a match for any possible ignore option rather than for no such option; this meant that these statements were always ignored. Now, if there is no current database, a statement using fully qualified table names is always written to the binary log.
- InnoDB: Valgrind testing returned memory leak errors which resulted from a regression . The dict_create_add_foreign_to_dictionary function would call pars_info_create but failed to call pars_info_free.
- InnoDB: The fix for resulted in a linker error.
- InnoDB: Crash recovery would fail with a !recv_no_log_write assertion when reading a page.
- Replication: Using the --replicate-* options (see Replication Slave Options and Variables) could in some cases lead to a memory leak on the slave.
- Replication: The binary log contents got corrupted sometimes, because the function MYSQL_BIN_LOG::write_cache always thought it had reached the end-of-cache when the function my_b_fill() reported a '0,' while that could also mean an error had occurred. This fix makes sure that whenever my_b_fill() returns a '0,' an error check is performed on info->error.
- The WKB reader for spatial operations could fail and cause a server exit.
- A GROUP_CONCAT() invocation containing subquery having an outer reference caused the server to exit.
- For debug builds, GROUP_CONCAT(... ORDER BY) within an ORDER BY clause could cause a server exit.
- If loose index scan was used on a query that used MIN(), a segmentation fault could occur.
- A prepared statement that used GROUP_CONCAT() and an ORDER BY clause that named multiple columns could cause the server to exit.
- ORDER BY MATCH ... AGAINST could cause a server exit.
- When a partition is missing, code in ha_innodb.cc would retry 10 times and sleep for a microsecond each time while holding LOCK_open. The retry logic for partitioned tables was introduced as a fix but did not include a test case to validate it. This fix removes the retry logic for partitioned tables. If the problem reported reappears, a different solution will be explored.
- The mysql.server script exited with an error if the status command was executed with multiple servers running.
- When processing row-based-replication events in the old binary log format from prior to MySQL 5.1 GA builds, mysqlbinlog could result in out-of-bounds heap buffer reads and undefined behaviour.
- The mysql client allocated but did not free a string after reading each line in interactive mode, resulting in a memory leak.
- Grouping by an outer BLOB column in a subquery caused a server exit.
- The url columns in the mysql datatbase help tables were too short to hold some of the URLs in the help content. For new installations, these columns are now created as type TEXT to accommodate longer URLs.
- For upgrades, mysql_upgrade does not update the columns. Modify them manually using these statements:
ALTER TABLE mysql.help_category MODIFY url TEXT NOT NULL;
ALTER TABLE mysql.help_topic MODIFY url TEXT NOT NULL;
- The test for stack overrun did not work for recent gcc versions and could lead to server exit.
- IF() function evaluations could produce different results when executed in a prepared versus nonprepared statement.