MySQL :: MySQL 5.7 Release Notes :: Changes in MySQL 5.7.1 (2013-04-23, Milestone 11)

9.5
9.4
9.3
9.2
9.1
9.0
8.4 current
8.3
8.2
8.1
8.0

MySQL 5.7 Release Notes / Changes in MySQL 5.7.1 (2013-04-23, Milestone 11)

Changes in MySQL 5.7.1 (2013-04-23, Milestone 11)

Note

This is a milestone release, for use at your own risk. Upgrades between milestone releases (or from a milestone release to a GA release) are not supported. Significant development changes take place in milestone releases and you may encounter compatibility issues, such as data format changes that require attention in addition to the usual procedure of running mysql_upgrade. For example, you may find it necessary to dump your data with mysqldump before the upgrade and reload it afterward. (Making a backup before the upgrade is a prudent precaution in any case.)

Audit Log Notes

Several changes were made to the audit log plugin for better compatibility with Oracle Audit Vault.

The format of the audit log file has changed:
- Information within <AUDIT_RECORD> elements written in the old format using attributes is written in the new format using subelements.
- The new format includes more information in <AUDIT_RECORD> elements. Every element includes a RECORD_ID value providing a unique identifier. The TIMESTAMP value includes time zone information. Query records include HOST, IP, OS_LOGIN, and USER information, as well as COMMAND_CLASS and STATUS_CODE values.
  
  The STATUS_CODE value differs from the existing STATUS value: STATUS_CODE is 0 for success and 1 for error, which is compatible with the EZ_collector consumer for Audit Vault. STATUS is the value of the mysql_errno() C API function. This is 0 for success and nonzero for error, and thus is not necessarily 1 for error.
Example of old <AUDIT_RECORD> format:
```
<AUDIT_RECORD
 TIMESTAMP="2013-04-15T15:27:27" NAME="Query" CONNECTION_ID="3" STATUS="0" SQLTEXT="SELECT 1"/>
```
Example of new <AUDIT_RECORD> format:
```
<AUDIT_RECORD>
 <TIMESTAMP>2013-04-15T15:27:27 UTC</TIMESTAMP>
 <RECORD_ID>3998_2013-04-15T15:27:27</RECORD_ID>
 <NAME>Query</NAME>
 <CONNECTION_ID>3</CONNECTION_ID>
 <STATUS>0</STATUS>
 <STATUS_CODE>0</STATUS_CODE>
 <USER>root[root] @ localhost [127.0.0.1]</USER>
 <OS_LOGIN></OS_LOGIN>
 <HOST>localhost</HOST>
 <IP>127.0.0.1</IP>
 <COMMAND_CLASS>select</COMMAND_CLASS>
 <SQLTEXT>SELECT 1</SQLTEXT>
</AUDIT_RECORD>
```
When the audit log plugin rotates the audit log file, it uses a different file name format. For a log file named audit.log, the plugin previously renamed the file to audit.log.TIMESTAMP. The plugin now renames the file to audit.log.TIMESTAMP.xml to indicate that it is an XML file.

For information about the audit log plugin, see MySQL Enterprise Audit.

If you previously used an older version of the audit log plugin, use this procedure to avoid writing new-format log entries to an existing log file that contains old-format entries:
1. Stop the server.
2. Rename the current audit log file manually. This file will contain only old-format log entries.
3. Update the server and restart it. The audit log plugin will create a new log file, which will contain only new-format log entries.
The API for writing audit plugins has also changed. The mysql_event_general structure has new members to represent client host name and IP address, command class, and external user. For more information, see Writing Audit Plugins. (WL #6715)

Connection Management Notes

The following changes were made to the sandbox mode that the server uses to handle client connections for accounts with expired passwords:
- There is a new disconnect_on_expired_password system variable (default: enabled). This controls how the server treats expired-password accounts.
- Two flags were added to the C API client library: MYSQL_OPT_CAN_HANDLE_EXPIRED_PASSWORDS for mysql_options() and CLIENT_CAN_HANDLE_EXPIRED_PASSWORDS for mysql_real_connect(). Each flag enables a client program to indicate whether it can handle sandbox mode for accounts with expired passwords.
  
  MYSQL_OPT_CAN_HANDLE_EXPIRED_PASSWORDS is enabled for mysqltest unconditionally, for mysql in interactive mode, and for mysqladmin if the first command is password.
For more information about how the client-side flags interact with disconnect_on_expired_password, see Server Handling of Expired Passwords. (Bug #67568, Bug #15874023, WL #6587)

Deprecation and Removal Notes

The deprecated innodb_mirrored_log_groups system variable has been removed. (WL #6808)

Functionality Added or Changed

Incompatible Change: SHOW ENGINE PERFORMANCE_SCHEMA STATUS output used a mix of row_count and count attributes. These are now all count. Similarly, the output used a mix of row_size and size attributes. These are now all size. (Bug #16165468)
Performance: String hashing overhead was reduced. This also improves performance for metadata locking, the table definition cache, and Performance Schema table I/O and file I/O instrumentation. (Bug #13944392)
InnoDB: Non-compressed, user-created InnoDB temporary tables and on-disk internal InnoDB temporary tables are now created in a shared temporary tablespace. The innodb_temp_data_file_path configuration option defines the relative path, name, size, and attributes for temporary tablespace data files. If no value is specified for innodb_temp_data_file_path, the default behavior is to create an auto-extending data file named ibtmp1 in the data directory that is slightly larger than 12MB. The shared temporary tablespace is removed and recreated each time the server is started.

In previous releases, temporary tables are created in individual file-per-table tablespaces in the temporary file directory, or in the InnoDB system tablespace in the data directory if innodb_file_per_table is disabled. Compressed temporary tables are still created in file-per-table tablespaces in the temporary file directory.

A shared temporary tablespace removes performance costs associated with creating and removing a file-per-table tablespace for each temporary table. A dedicated temporary tablespace also means that it is no longer necessary to save temporary table metadata to the InnoDB system tables. (WL #6560)
InnoDB: Prior to this release, InnoDB stored spatial data types as binary BLOB data, mapped to the internal DATA_BLOB data type. BLOB remains the underlying data type but spatial data types are now mapped to a new internal data type, DATA_GEOMETRY. With BLOB as the underlying data type, a prefix index can still be used on all GEOMETRY data type columns.
InnoDB: DDL performance for user and system-created InnoDB temporary tables was optimized by avoiding operations that are only necessary for regular InnoDB tables. Those operations include redo logging (required for recovery), writing of table definition metadata to InnoDB system tables, and insert buffering. DDL operations that benefit from the optimization include CREATE TABLE, DROP TABLE, TRUNCATE TABLE, and ALTER TABLE, including ALTER TABLE ... IMPORT TABLESPACE and ALTER TABLE ... DISCARD TABLESPACE.

As a result of the optimization, InnoDB temporary table metadata no longer appears in INFORMATION_SCHEMA views that previously included that data. Instead, a new INFORMATION_SCHEMA table, INNODB_TEMP_TABLE_INFO, provides a snapshot of active user-created temporary tables within an InnoDB instance. Additionally, the number of InnoDB temporary tables that can exist at one time is now limited by the amount of memory available (for temporary table definitions) on the system that runs the MySQL server process, as temporary table definitions can no longer be placed on the LRU list and swapped out. (WL #6469)
InnoDB: DDL performance for InnoDB temporary tables is improved through optimization of CREATE TABLE, DROP TABLE, TRUNCATE TABLE, and ALTER TABLE statements. Optimizations were achieved by limiting actions performed by DDL statements to only those necessary for temporary tables.
InnoDB: VARCHAR column size can now be increased using an in-place ALTER TABLE, as in this example:
```
ALTER TABLE t1 ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(255);
```
This is true as long as the number of length bytes required by a VARCHAR column remains the same. For VARCHAR columns of 0 to 255 bytes in size, one length byte is required to encode the value. For VARCHAR columns of 256 bytes in size or more, two length bytes are required. As a result, in-place ALTER TABLE only supports increasing VARCHAR column size from 0 to 255 bytes, or from 256 bytes to a greater size. In-place ALTER TABLE does not support increasing the size of a VARCHAR column from less than 256 bytes to a size equal to or greater than 256 bytes. In this case, the number of required length bytes changes from 1 to 2, which is only supported by a table copy (ALGORITHM=COPY).

Decreasing VARCHAR size using in-place ALTER TABLE is not supported. Decreasing VARCHAR size requires a table copy (ALGORITHM=COPY).

For more information, see Online DDL Operations.
InnoDB: Online index renaming is supported by ALTER TABLE, which now includes a RENAME INDEX clause, as shown in the following example: “ALTER TABLE t RENAME INDEX i1 TO i2”, where i1 is the current name of the index and i2 is the new name.

The result of “ALTER TABLE t RENAME INDEX i1 TO i2” would be a table with contents and structure that is identical to the old version of “t1” except for the index name, which is now “i2” instead of “i1”.
Partitioning: HANDLER statements are now supported with partitioned tables. (WL #6497)
Replication: An Auto_Position column has been added to the output generated by SHOW SLAVE STATUS. The value of this column shows whether replication autopositioning is in use. If autopositioning is enabled—that is, if MASTER_AUTO_POSITION = 1 was set by the last successful CHANGE MASTER TO statement that was executed on the slave—then the column's value is 1; if not, then the value is 0. (Bug #15992220)
Replication: The functions GTID_SUBTRACT() and GTID_SUBSET() were formerly available in libmysqld only when it was built with replication support. Now these functions are always available when using this library, regardless of how it was built.
Replication: Added the --rewrite-db option for mysqlbinlog, which allows mysqlbinlog to rewrite the names of databases when playing back binary logs written using the row-based logging format. Multiple rewrite rules can be created by specifying the option multiple times. (WL #6404)
MySQL no longer uses the default OpenSSL compression. (Bug #16235681)
There is now a distinct error code (ER_MUST_CHANGE_PASSWORD_LOGIN) for the error sent by the server to a client authenticating with an expired password. (Bug #16102943)
In RPM packages built for Unbreakable Linux Network, libmysqld.so now has a version number. (Bug #15972480)
Error messages for ALTER TABLE statement using a LOCK or ALGORITHM value not supported for the given operation were very generic. The server now produces more informative messages. (Bug #15902911)
If a client with an expired password connected but old_passwords was not the value required to select the password hashing format appropriate for the client account, there was no way for the client to determine the proper value. Now the server automatically sets the session old_passwords value appropriately for the account authentication method. For example, if the account uses the sha256_password authentication plugin, the server sets old_passwords=2. (Bug #15892194)
mysqldump now supports an --ignore-error option. The option value is a comma-separated list of error numbers specifying the errors to ignore during mysqldump execution. If the --force option is also given to ignore all errors, --force takes precedence. (Bug #15855723)
mysql_config_editor now supports --port and --socket options for specifying TCP/IP port number and Unix socket file name. (Bug #15851247)
mysqlcheck has a new --skip-database option. The option value is the name of a database (case sensitive) for which checks should be skipped.

mysql_upgrade adds this option to mysqlcheck commands that it generates to upgrade the system tables in the mysql database before tables in other databases: It upgrades the mysql database, then all databases except the mysql database. This avoids problems that can occur if user tables are upgraded before the system tables. (Bug #14697538, Bug #68163, Bug #16216384)
The validate_password_policy_number system variable was renamed to validate_password_policy. (Bug #14588121)
Previously, on Linux the server failed to perform stack backtrace attempts for versions of glibc older than the current minimum supported version (2.3). Now on such attempts the server displays a message that the glibc version is too old to support backtracing. (Bug #14475946)
In JSON-format EXPLAIN output, the attached_condition information for subqueries now includes select# to indicate the relative order of subquery execution. (Bug #13897507)
If a user attempted to access a nonexistent column for which the user had no access, the server returned an error indicating that the column did not exist. Now the server returns an error indicating that the user does not have privileges for the column, which provides no information about column existence. (Bug #19947, Bug #11745788)
The MySQL test suite mysql-test-run.sh program now starts the server with InnoDB rather than MyISAM as the default storage engine. To maintain compatibility of test results with existing result files, test cases were modified to add a line that includes the force_default_myisam.inc file as necessary. In a future release, for those test cases not specifically requiring MyISAM, that line will be removed (so they run with InnoDB) and test results will be updated. (WL #6731)
ALTER TABLE now supports a RENAME INDEX clause that renames an index. The change is made in place without a table-copy operation. (WL #6555)
The mysql client now has a --syslog option that causes interactive statements to be sent to the system syslog facility. Logging is suppressed for statements that match the default “ignore” pattern list ("*IDENTIFIED*:*PASSWORD*"), as well as statements that match any patterns specified using the --histignore option. For more information, see mysql Client Logging. (WL #6788)

Bugs Fixed

Incompatible Change; Partitioning: Changes in the KEY partitioning hashing functions used with numeric, date and time, ENUM, and SET columns in MySQL 5.5 makes tables using partitioning or subpartitioning by KEY on any of the affected column types and created on a MySQL 5.5 or later server incompatible with a MySQL 5.1 server. This is because the partition IDs as calculated by a MySQL 5.5 or later server almost certainly differ from those calculated by a MySQL 5.1 server for the same table definition and data as a result of the changes in these functions.

The principal changes in the KEY partitioning implementation in MySQL 5.5 resulting in this issue were as follows: 1. The hash function used for numeric and date and time columns changed from binary to character-based. 2. The base used for hashing of ENUM and SET columns changed from latin1 ci characters to binary.

The fix involves adding the capability in MySQL 5.5 and later to choose which type of hashing to use for KEY partitioning, which is implemented with a new ALGORITHM extension to the PARTITION BY KEY option for CREATE TABLE and ALTER TABLE. Specifying PARTITION BY KEY ALGORITHM=1 ([columns]) causes the server to use the hashing functions as implemented in MySQL 5.1; using ALGORITHM=2 causes the server to use the hashing functions from MySQL 5.5 and later. ALGORITHM=2 is the default. Using the appropriate value for ALGORITHM, you can perform any of the following tasks:
- Create KEY partitioned tables in MySQL 5.5 and later that are compatible with MySQL 5.1, using CREATE TABLE ... PARTITION BY KEY ALGORITHM=1 (...).
- Downgrade KEY partitioned tables that were created in MySQL 5.5 or later to become compatible with MySQL 5.1, using ALTER TABLE ... PARTITION BY KEY ALGORITHM=1 (...).
- Upgrade KEY partitioned tables originally created in MySQL 5.1 to use hashing as in MySQL 5.5 and later, using ALTER TABLE ... PARTITION BY KEY ALGORITHM=2 (...).
  
  Important: After such tables are upgraded, they cannot be used any longer with MySQL 5.1 unless they are first downgraded again using ALTER TABLE ... PARTITION BY KEY ALGORITHM=1 (...) on a MySQL server supporting this option.
This syntax is not backward compatible, and causes errors in older versions of the MySQL server. When generating CREATE TABLE ... PARTITION BY KEY statements, mysqldump brackets any occurrence of ALGORITHM=1 or ALGORITHM=2 in conditional comments such that it is ignored by a MySQL server whose version is not at least 5.5.31. An additional consideration for upgrades is that MySQL 5.6 servers prior to MySQL 5.6.11 do not ignore the ALGORITHM option in such statements when generated by a MySQL 5.5 server, due to the that the conditional comments refer to version 5.5.31; in this case, you must edit the dump manually and remove or comment out the option wherever it occurs before attempting to load it into a MySQL 5.6.10 or earlier MySQL 5.6 server. This is not an issue for dumps generated by MySQL 5.6.11 or later version of mysqldump, where the version used in such comments is 5.6.11. For more information, see ALTER TABLE Partition Operations.

As part of this fix, a spurious assertion by InnoDB that a deleted row had previously been read, causing the server to assert on delete of a row that the row was in the wrong partition, was also removed. (Bug #14521864, Bug #66462, Bug #16093958, Bug #16274455)

References: See also: Bug #11759782.
Incompatible Change: For debug builds, creating an InnoDB table in strict SQL mode that violated the maximum key length limit caused the server to exit.

A behavior change in consequence of this bug fix: In strict SQL mode, a key length limit violation now results in a error (and the table is not created), rather than a warning and truncation of the key to the maximum key length. This applies to all storage engines. (Bug #16035659)
Important Change; Plugin API; Replication: Because the behavior of the fulltext plugin may vary between MySQL servers, it is not possible to guarantee that statements using this plugin produce the same results on masters and slaves. For this reason, statements depending on the fulltext plugin are now marked as unsafe for statement-based logging. This means that such statements are logged using row format when binlog_format=MIXED, and cause a warning to be generated when binlog_format=STATEMENT. (Bug #11756280, Bug #48183)
Important Change; Replication

Important

This fix was reverted in MySQL 5.7.2. See Changes in MySQL 5.7.2 (2013-09-21, Milestone 12).

Executing a statement that performs an implicit commit but whose changes are not logged when gtid_next is set to any value other than AUTOMATIC is not permitted. Now in such cases, the statement fails with an error. This includes the statements in the following list:
(Bug #16062608)

References: See also: Bug #16484323.
Important Change; Replication: The version number reported by mysqlbinlog --version has been increased to 3.4. (Bug #15894381, Bug #67643)
Important Change; Replication: The lettercasing used for displaying UUIDs in global transaction identifiers was inconsistent. Now, all GTID values use lowercase, including those shown in the Retrieved_Gtid_Set and Executed_Gtid_Set columns from the output of SHOW SLAVE STATUS. (Bug #15869441)
Important Note; Replication: Using row-based logging to replicate from a table to a same-named view led to a failure on the slave. Now, when using row-based logging, the target object type is checked prior to performing any DML, and an error is given if the target on the slave is not actually a table.

Note

It remains possible to replicate from a table to a same-named view using statement-based logging.

(Bug #11752707, Bug #43975)
Performance; InnoDB: The DROP TABLE statement for a table using compression could be slower than necessary, causing a stall for several seconds. MySQL was unnecessarily decompressing pages in the buffer pool related to the table as part of the DROP operation. (Bug #16067973)
NDB Cluster: The setting for the DefaultOperationRedoProblemAction API node configuration parameter was ignored, and the default value used instead. (Bug #15855588)
NDB Cluster: Job buffers act as the internal queues for work requests (signals) between block threads in ndbmtd and could be exhausted if too many signals are sent to a block thread.

Performing pushed joins in the DBSPJ kernel block can execute multiple branches of the query tree in parallel, which means that the number of signals being sent can increase as more branches are executed. If DBSPJ execution cannot be completed before the job buffers are filled, the data node can fail.

This problem could be identified by multiple instances of the message sleeploop 10!! in the cluster out log, possibly followed by job buffer full. If the job buffers overflowed more gradually, there could also be failures due to error 1205 (Lock wait timeout exceeded), shutdowns initiated by the watchdog timer, or other timeout related errors. These were due to the slowdown caused by the 'sleeploop'.

Normally up to a 1:4 fanout ratio between consumed and produced signals is permitted. However, since there can be a potentially unlimited number of rows returned from the scan (and multiple scans of this type executing in parallel), any ratio greater 1:1 in such cases makes it possible to overflow the job buffers.

The fix for this issue defers any lookup child which otherwise would have been executed in parallel with another is deferred, to resume when its parallel child completes one of its own requests. This restricts the fanout ratio for bushy scan-lookup joins to 1:1. (Bug #14709490)

References: See also: Bug #14648712.
NDB Cluster: The recently added LCP fragment scan watchdog occasionally reported problems with LCP fragment scans having very high table id, fragment id, and row count values.

This was due to the watchdog not accounting for the time spent draining the backup buffer used to buffer rows before writing to the fragment checkpoint file.

Now, in the final stage of an LCP fragment scan, the watchdog switches from monitoring rows scanned to monitoring the buffer size in bytes. The buffer size should decrease as data is written to the file, after which the file should be promptly closed. (Bug #14680057)
InnoDB: When parsing a delimited search string such as “abc-def” in a full-text search, InnoDB now uses the same word delimiters as MyISAM. (Bug #16419661)
InnoDB: Naming inconsistencies were addressed for InnoDB PERFORMANCE_SCHEMA key declarations. (Bug #16414044)
InnoDB: Status values in the innodb_ft_config table would not update. The innodb_ft_config is intended for internal configuration and should not be used for statistical information purposes. To avoid confusion, column values that are intended for internal use have been removed from the innodb_ft_config table. This fix also removes the innodb_ft_config table and other internal full text search-related tables that were unintentionally exposed. (Bug #16409494, Bug #68502)
InnoDB: This fix disables a condition for extra splitting of clustered index leaf pages, on compressed tables. Extra page splitting was only done to reserve space for future updates, so that future page splits could be avoided. (Bug #16401801)
InnoDB: For InnoDB tables, if a PRIMARY KEY on a VARCHAR column (or prefix) was empty, index page compression could fail. (Bug #16400920)
InnoDB: The InnoDB page-splitting algorithm could recurse excessively. (Bug #16345265)
InnoDB: Improper testing of compatibility between the referencing and referenced during ALTER TABLE ... ADD FOREIGN key could cause a server exit. (Bug #16330036)
InnoDB: Importing a tablespace with the configuration file present would not import the data file. This problem would occur when all pages are not flushed from the buffer pool after a table is altered using the copy and rename approach. This fix ensures that all pages are flushed from the buffer pool when a table is altered using the copy and rename approach. (Bug #16318052)
InnoDB: Rollback did not include changes made to temporary tables by read-only transactions. (Bug #16310467)
InnoDB: When using ALTER TABLE to set an AUTO_INCREMENT column value to a user-specified value, InnoDB would set the AUTO_INCREMENT value to the user-specified value even when the AUTO_INCREMENT value is greater than the user-specified value. This fix ensures that the AUTO_INCREMENT value is set to the maximum of the user-specified value and MAX(auto_increment_column)+1, which is the expected behaviour. (Bug #16310273)
InnoDB: For debug builds, InnoDB status exporting was subject to a race condition that could cause a server exit. (Bug #16292043)
InnoDB: With innodb_api_enable_mdl=OFF, an ALTER TABLE operation on an InnoDB table that required a table copy could cause a server exit. (Bug #16287411)
InnoDB: An assertion failure would occur in heap->magic_n == MEM_BLOCK_MAGIC_N due to a race condition that appeared when row_merge_read_clustered_index() returned an error. (Bug #16275237)
InnoDB: InnoDB now aborts execution on Windows by calling the abort() function directly, as it does on other platforms. (Bug #16263506)
InnoDB: This fix removes an unnecessary debug assertion related to page_hash locks which only affects debug builds. The debug assertion is no longer valid and should have been removed when hash_lock array was introduced in MySQL 5.6. (Bug #16263167)
InnoDB: Without warning, InnoDB would silently set innodb-buffer-pool-instances to 1 if the buffer pool size is less than 1GB. For example, if innodb-buffer-pool-size is set to 200M and innodb-buffer-pool-instances is set to 4, InnoDB would silently set innodb-buffer-pool-instances to 1. This fix implements a warning message and new logic for innodb-buffer-pool-size and innodb-buffer-pool-instances. (Bug #16249500, Bug #61239)
InnoDB: The lock_validate function, which is only present in debug builds, acquired and released mutexes to avoid hogging them. This behavior introduced a window wherein changes to the hash table could occur while code traversed the same set of data. This fix updates lock_validate logic to collect all records for which locks must be validated, releases mutexes, and runs a loop to validate record locks. (Bug #16235056)
InnoDB: ALTER TABLE functions would perform a check to see if InnoDB is in read-only mode (srv_read_only_mode=true). If InnoDB was in read-only mode, the check would return a successful status and do nothing else. This fix replaces srv_read_only_mode check conditions with debug assertions. (Bug #16227539)
InnoDB: When the InnoDB buffer pool is almost filled with 4KB compressed pages, inserting into 16KB compact tables would cause 8KB pages_free to increase, which could potentially slow or stall inserts. (Bug #16223169)
InnoDB: This fix updates InnoDB code in ha_innodb.cc and handler0alter.cc to use TABLE::key_info instead of both TABLE::key_info and TABLE_SHARE::key_info. (Bug #16215361)
InnoDB: When InnoDB locking code was revised, a call to register lock waits was inadvertently removed. This fix adds the call back to the InnoDB locking code. (Bug #16208201)
InnoDB: A direct call to the trx_start_if_not_started_xa_low() function would cause a debug assertion. (Bug #16178995)
InnoDB: In the case of LOCK WAIT for an insert in a foreign key table, InnoDB could report a false dictionary-changed error and cause the insert to fail rather than being retried. (Bug #16174255)
InnoDB: An in-place ALTER TABLE on an InnoDB table could fail to delete the statistics for the old primary key from the mysql.innodb_index_stats table. (Bug #16170451)
InnoDB: In some cases, deadlock detection did not work, resulting in sessions hanging waiting for a lock-wait timeout. (Bug #16169638)
InnoDB: When the primary key of a table includes a column prefix, and a full-text index is defined on the table, a full-text search resulted in an unnecessary warning being written to the error log. This fix suppresses the unnecessary warning. (Bug #16169411)
InnoDB: LOCK_TIME would not be logged correctly in the slow query log. LOCK_TIME did not account for InnoDB row lock wait time. (Bug #16097753)
InnoDB: Arithmetic underflow during page compression for CREATE TABLE on an InnoDB table could cause a server exit. (Bug #16089381)
InnoDB: For debug builds, online ALTER TABLE operations for InnoDB tables could cause a server exit during table rebuilding. (Bug #16063835)
InnoDB: In some cases, the InnoDB purge coordinator did not use all available purge threads, resulting in suboptimal purge activity. (Bug #16037372)
InnoDB: ALTER TABLE for InnoDB tables was not fully atomic. (Bug #15989081)
InnoDB: This fix replaces most uses of UT_SORT_FUNCTION_BODY, an InnoDB recursive merge sort, with the std::sort() function from the C++ Standard Template Library (STL). The std::sort() function requires less memory and is faster due to in-line execution. (Bug #15920744)
InnoDB: This fix addresses unnecessary buffer pool lookups that would occur while freeing blob pages, and implements a debug status instrument, innodb_ahi_drop_lookups, for testing purposes. (Bug #15866009)
InnoDB: This fix implements a 256-byte boundary for extending a VARCHAR column instead of 256-character boundary. This change allows for in-place extension of a VARCHAR column through an update of the data dictionary. (Bug #15863023)
InnoDB: Creating numerous tables, each with a full-text search index, could result in excessive memory consumption. This bug fix adds a new configuration parameter, innodb_ft_total_cache_size, which defines a global memory limit for full-text search indexes. If the global limit is reached by an index operation, a force sync is triggered. (Bug #14834698, Bug #16817453)
InnoDB: This fix modifies InnoDB code to ensure that unused thread handles are closed when the thread exits, instead of leaving thread handles open until shutdown of mysqld on Windows. (Bug #14762796)
InnoDB: This fix removes unnecessary overhead by removing table locking and disabling read view creation and MVCC when InnoDB is started in read-only mode (--innodb-read-only=true). (Bug #14729365)
InnoDB: A regression introduced by the fix for Bug#14100254 would result in a “!BPAGE->FILE_PAGE_WAS_FREED” assertion. (Bug #14676249)
InnoDB: Full-text search (FTS) index savepoint information would not be set resulting in a severe error when attempting to rollback to the savepoint. (Bug #14639605, Bug #17456092)
InnoDB: The innodb_sync_array_size variable was incorrectly allowed to be configured at runtime. As documented, innodb_sync_array_size must be configured when the MySQL instance is starting up, and cannot be changed afterward. This fix changes innodb_sync_array_size to a non-dynamic variable, as intended. (Bug #14629979)
InnoDB: An error at the filesystem level, such as too many open files, could cause an unhandled error during an ALTER TABLE operation. The error could be accompanied by Valgrind warnings, and by this assertion message:
```
Assertion `! is_set()' failed.
mysqld got signal 6 ;
```
(Bug #14628410, Bug #16000909)
InnoDB: The server could exit during an attempt by InnoDB to reorganize or compress a compressed secondary index page. (Bug #14606334)
InnoDB: A DML operation performed while a RENAME TABLE operation waits for pending I/O operations on the tablespace to complete would result in a deadlock. (Bug #14556349)
InnoDB: Attempting to unninstall the InnoDB memcached plugin while the plugin is still installing caused the Mysql server to terminate. While the plugin deamon thread was still initializing, plugin variables were not yet set and the uninstall process could not cleanup resources. This fix adds a variable to indicate initialization status. If initialization is incomplete, the uninstall process will wait. (Bug #14279541)
InnoDB: If the value of innodb_force_recovery was less than 6, opening a corrupted table might loop forever if a corrupted page was read when calculating statistics for the table. Information about the corrupted page was written repeatedly to the error log, possibly causing a disk space issue. The fix causes the server to halt after a fixed number of failed attempts to read the page. To troubleshoot such a corruption issue, set innodb_force_recovery=6 and restart. (Bug #14147491, Bug #65469)
InnoDB: When printing out long semaphore wait diagnostics, sync_array_cell_print() ran into a segmentation violation (SEGV) caused by a race condition. This fix addresses the race condition by allowing the cell to be freed while it is being printed. (Bug #13997024)
InnoDB: Attempting to replace the default InnoDB full-text search (FTS) stopword list by creating an InnoDB table with the same structure as INFORMATION_SCHEMA.INNODB_FT_DEFAULT_STOPWORD would result in an error. SHOW CREATE TABLE revealed that the new InnoDB table was created with CHARSET=utf8. The InnoDB FTS stopword table validity check only supported latin1. This fix extends the validity check for all supported character sets. (Bug #68450, Bug #16373868)
InnoDB: This fix removes left-over prototype code for srv_parse_log_group_home_dirs, and related header comments. (Bug #68133, Bug #16198764)
InnoDB: Killing a query caused an InnoDB assertion failure when the same table (cursor) instance was used again. This is the result of a regression error introduced by the fix for Bug#14704286. The fix introduced a check to handle kill signals for long running queries but the cursor was not restored to the proper state. (Bug #68051, Bug #16088883)
InnoDB: On startup, InnoDB reported a message on 64-bit Linux and 64-bit Windows systems stating that the CPU does not support crc32 instructions. On Windows, InnoDB does not use crc32 instructions even if supported by the CPU. This fix revises the wording of the message and implements a check for availability of crc32 instructions. (Bug #68035, Bug #16075806)
InnoDB: The length of internally generated foreign key names was not checked. If internally generated foreign key names were over the 64 character limit, this resulted in invalid DDL from SHOW CREATE TABLE. This fix checks the length of internally generated foreign key names and reports an error message if the limit is exceeded. (Bug #44541, Bug #11753153)
Partitioning: A query on a table partitioned by range and using TO_DAYS() as a partitioing function always included the first partition of the table when pruning. This happened regardless of the range employed in the BETWEEN clause of such a query. (Bug #15843818, Bug #49754)
Partitioning: Partition pruning is now enabled for tables using a storage engine that provides automatic partitioning, such as the NDB storage engine, but which are explicitly partitioned. Previously, pruning was disabled for all tables using such a storage engine, whether or not the tables had explicitly defined partitions.

In addition, as part of this fix, explicit partition selection is now disabled for tables using a storage engine (such as NDB) that provides automatic partitioning. (Bug #14827952)

References: See also: Bug #14672885.
Partitioning: Execution of ALTER TABLE ... DROP PARTITION against a view caused the server to crash, rather than fail with an error as expected. (Bug #14653504)
Partitioning: A query result was not sorted if both DISTINCT and ORDER BY were used and the underlying table was partitioned. (Bug #14058167)
Partitioning: Inserting any number of rows into an ARCHIVE table that used more than 1000 partitions and then attempting to drop the table caused the MySQL Server to fail. (Bug #13819630, Bug #64580)
Replication; Linux; Microsoft Windows: Replication failed between a Linux master using lower_case_table_names set to 0 and a Windows slave having lower_case_table_names set to 2, after a replicated table was opened on the slave; in addition, FLUSH TABLES was required afterwards to see which updates had actually been applied on the slave. This was because lower_case_table_names was checked only to see whether it was equal to 1 prior to forcing a conversion of replicated database object names to lower case for checking the table cache. Now in such cases, lower_case_table_names is checked to see whether it is set to a nonzero value. (Bug #16061982)
Replication; Microsoft Windows: When the binlog.index file ended with \r\n (CR+LF), MySQL wrongly included the \r character in the name of the file it tried to open, causing replication to fail. This could cause problems with restarting the server after editing this file on a Windows system. (Bug #11757413, Bug #49455)
Replication: When using GTIDs and binary log auto-positioning, the master had to scan all binary logs whenever the slave reconnected (due to reasons such as I/O thread failure or a change of master) before it could send any events to slave. Now, the master starts from the oldest binary log that contains any GTID not found on the slave. (Bug #16340322, Bug #68386)
Replication: When the server version of the master was greater than or equal to 10, replication to a slave having a lower server version failed. (Bug #16237051, Bug #68187)
Replication: When replicating to a MySQL 5.6 master to an older slave, Error 1193 (ER_UNKNOWN_SYSTEM_VARIABLE) was logged with a message such as Unknown system variable 'SERVER_UUID' on master, maybe it is a *VERY OLD MASTER*. This message has been improved to include more information, similar to this one: Unknown system variable 'SERVER_UUID' on master. A probable cause is that the variable is not supported on the master (version: 5.5.31), even though it is on the slave (version: 5.6.11). (Bug #16216404, Bug #68164)
Replication: The print format specifier for the server_id was incorrectly defined as a signed 32-bit integer with a range of -2144783647 to 2144783648. This fix changes the server_id integer type to an unsigned 32-bit integer type, with a range of 0 to 4294967295, which is the documented range for the --server-id option. (Bug #16210894)
Replication: When MTS is on and transactions are being applied, the slave coordinator would hang when encountering a checksum error on a transaction event. This was due to a deadlock situation in which the coordinator assumed a normal stop while a worker waited for the coordinator to dispatch more events. For debug builds, the problem appeared as an assertion failure, which was due to the coordinator not setting thd->is_error() when encountering an error. (Bug #16210351)
Replication: A zero-length name for a user variable (such as @``) was incorrectly considered to be a sign of data or network corruption when reading from the binary log. (Bug #16200555, Bug #68135)
Replication: Running SHOW RELAYLOG EVENTS at a slave where no relay log file is present returned the following incorrect error message: "Error when executing command SHOW BINLOG EVENTS: Could not find target log." The error message text has been changed to: "Error when executing command SHOW RELAYLOG EVENTS: Could not find target log." (Bug #16191895)
Replication: mysqlbinlog can connect to a remote server and read its binary logs. In MySQL 5.6 and later, this tool can also wait for the server to generate and send additional events, in practice behaving like a slave connecting to a master. In cases where the server sent a heartbeat, mysqlbinlog was unable to handle it properly. As a consequence, mysqlbinlog failed at this point, without reading any more events from the server. To fix this problem, mysqlbinlog now ignores any binary log events of type HEARTBEAT_LOG_EVENT that it receives. (Bug #16104206)
Replication: STOP SLAVE could cause a deadlock when issued concurrently with a statement such as SHOW STATUS that retrieved the values for one or more of the status variables Slave_retried_transactions, Slave_heartbeat_period, Slave_received_heartbeats, Slave_last_heartbeat, or Slave_running. (Bug #16088188, Bug #67545)

References: See also: Bug #16088114.
Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on the slave. (Bug #16084594, Bug #68045)

References: This issue is a regression of: Bug #14548159, Bug #66550.
Replication: In order to provision or to restore a server using GTIDs, it is possible to set gtid_purged to a given GTID set listing the transactions that were imported. This operation requires that the global gtid_executed and gtid_purged server system variables are empty. (This is done in order to avoid the possibility of overriding server-generated GTIDs.)

The error message GTID_PURGED can only be set when GTID_EXECUTED is empty that was raised when this requirement was not met could be confusing or misleading because it did not specify the scope of the affected variables. To prevent this from happening, error messages that refer to variables relating to GTIDs now specify the scope of any such variables when they do so. (Bug #16084426, Bug #68038)
Replication: The session-level value for gtid_next was incorrectly reset on the slave for all rollbacks, which meant that GTIDs could be lost for multi-statement transactions, causing the slave to stop with an ER_GTID_NEXT_TYPE_UNDEFINED_GROUP error. Now this is done only when a complete transaction is being rolled back, or when autocommit is enabled. (Bug #16084206)
Replication: Dropping a table that includes non-regular ASCII characters in the table name caused a replication failure. The parser converted the table name into standard charset characters and stored the table name in the table_name variable. When the drop table query was regenerated using the table_name variable, the table name was not converted back to the original charset.

Additionally, table and database names with 64 characters caused an assert failure. The assert required the table or database name to be less than 128 characters. Latin characters require two-bytes each, which requires an assert condition of less than or equal to 128 bits.

The fix includes a new function to convert tables names back to the original charset, and a correction to the assert condition allowing table and database names be less than or equal to 128 bits. (Bug #16066637)
Replication: Using the --replicate-* options (see Replica Server Options and Variables) could in some cases lead to a memory leak on the slave. (Bug #16056813, Bug #67983)
Replication: In some cases, when the slave could not recognize the server version of the master, this could cause the slave to fail. (Bug #16056365)
Replication: In certain cases, the dump thread could send a heartbeat out of synchronisation with format description events. One of the effects of this issue what that, after provisioning a new server from a backup data directory and setting --gtid-mode=ON and enabling autopositioning (see CHANGE MASTER TO Statement), replication failed to start, with the error Read invalid event from master.... The same problem could also cause GTID-based replication to fail due to skipped events following a unplanned shutdown of the master. (Bug #16051857)
Replication: Replication failed when a replicated LOAD DATA statement inserted rows into a view. (Bug #15993712, Bug #67878)
Replication: When using GTID-based replication, and whenever a transaction was executed on the master but was not sent to the slave because the slave already had a transaction with that ID, semisynchrononous replication timed out. One case in which this could happen was during a failover operation where the new master started behind the new slave. (Bug #15985893)
Replication: An unnecessary flush to disk performed after every transaction when using FILE as the replication info repository type could degrade performance. Now this is done only when both data and relay log info is stored in (transactional) tables. (Bug #15980626)
Replication: When a slave read a table map event from the binary log, it assumed that the metadata size was always less than twice the column count of the table in use, which failed when the event contained the wrong value for this field. (Bug #15830022)
Replication: When reading row log events from the binary log, the slave assumed that these events were always valid; because of this, an event having an invalid binary log offset could cause the slave to crash. Now in such cases, the slave fails gracefully, and an error is reported, if any of the fields in a given row event are invalid. (Bug #15829568)
Replication: Table IDs used in replication were defined as type ulong on the master and uint on the slave. In addition, the maximum value for table IDs in binary log events is 6 bytes (281474976710655). This combination of factors led to the following issues:
- Data could be lost on the slave when a table was assigned an ID greater than uint.
- Table IDs greater than 281474976710655 were written to the binary log as 281474976710655.
- This led to a stopped slave when the slave encountered two tables having the same table ID.
To fix these problems, IDs are now defined by both master and slave as type ulonglong but constrained to a range of 0 to 281474976710655, restarting from 0 when it exceeds this value. (Bug #14801955, Bug #67352)
Replication: MASTER_POS_WAIT() could hang or return -1 due to invalid updates by the slave SQL thread when transactions were skipped by the GTID protocol. (Bug #14775893)

References: See also: Bug #15927032.
Replication: Trying to execute a Stop event on a multithreaded slave could cause unwanted updates to the relay log, leading the slave to lose synchronization with the master. (Bug #14737388)
Replication: Internal objects used for relay log information were only partially deleted before freeing their memory. (Bug #14677824)
Replication: When the server starts, it checks whether semisynchronous replication has been enabled without a lock, and, if so, it takes the lock, then tests again. Disabling semisynchronous replication following the first of the these tests, but prior to the second one, could lead to a crash of the server. (Bug #14511533, Bug #66411)
Replication: It was possible in certain cases—immediately after detecting an EOF in the dump thread read event loop, and before deciding whether to change to a new binary log file—for new events to be written to the binary log before this decision was made. If log rotation occurred at this time, any events that occurred following EOF detection were dropped, resulting in loss of data. Now in such cases, steps are taken to make sure that all events are processed before allowing the log rotation to take place. (Bug #13545447, Bug #67929)

References: See also: Bug #16016886.
Replication: It was possible for the MASTER_POS_WAIT() function to return prematurely following a CHANGE MASTER TO statement that updated the RELAY_LOG_POS or RELAY_LOG_NAME. This could happen because CHANGE MASTER TO did not update the master log position in such cases, causing MASTER_POS_WAIT() to read an invalid log position and to return immediately.

To fix this problem, the master log position is flagged as invalid until the position is set to a valid value when the SQL thread reads the first event, after which it is flagged as valid. Functions such as MASTER_POS_WAIT() now defer any comparison with the master log position until a valid value can be obtained (that is, after the first event following the CHANGE MASTER TO statement has been applied). (Bug #11766010, Bug #59037)
Replication: If the disk becomes full while writing to the binary log, the server hangs until space is freed up manually. It was possible after this was done for the MySQL server to fail, due to an internal status value being set when not needed. Now in such cases, rather than trying to set this status, a warning is written in the error log instead. (Bug #11753923, Bug #45449)
Replication: The binary log and relay log files used the name of the PID file instead of the host name as the basename. (Bug #11753843, Bug #45359)
Microsoft Windows: A server started with --shared-memory to support shared-memory connections could crash when receiving requests from multiple threads. (Bug #13934876)
Microsoft Windows: On Windows, the log_error system variable did not accurately reflect the error log file name in some cases. For example, if the server was started without --console or --log-error, the default is to log to host_name.err in the data directory, but log_error remained blank.

Now log_error should be nonblank and reflect the log file name in all cases, on all platforms. The value is stderr if the server does not write error messages to a file and sends them to the console (standard error output) instead. In particular, on Windows, --console overrides use of an error log and sends error messages to the console, so log_error will be set to stderr. (Bug #8307, Bug #11745049)
Solaris: mysql_install_db did not work in Solaris 10 sparse root zones. (Bug #68117, Bug #16197860)
RPM packages were missing the innodb_engine.so and libmemcached.so plugins. (Bug #17001088)
Windows MSI installers for MySQL 5.7 had a 5.6 upgrade code, not a 5.7 upgrade code. (Bug #16445344)
SHOW ENGINE PERFORMANCE_SCHEMA STATUS could report incorrect memory-allocation values when the correct values exceeded 4GB. (Bug #16414644)
The server could exit if a prepared statement attempted to create a table using the name of an existing view while an SQL handler was opened. (Bug #16385711)
Performance Schema statement tokenization overhead was reduced. (Bug #16382260)
A long database name in a GRANT statement could cause the server to exit. (Bug #16372927)
Some aggregate queries attempted to allocate excessive memory. (Bug #16343992)
For debug builds, an assertion could be raised if a statement failed with autocommit enabled just before an XA START statement was issued. (Bug #16341673)
Very small join_buffer_size values could cause an assertion to be raised. (Bug #16328373)
The BUILD-CMAKE file in MySQL distributions was updated with the correct URL for CMake information. (Bug #16328024)
The optimizer's attempt to remove redundant subquery clauses raised an assertion when executing a prepared statement with a subquery in the ON clause of a join in a subquery. (Bug #16318585)

References: This issue is a regression of: Bug #15875919.
Incorrect results were returned if a query contained a subquery in an IN clause which contained an XOR operation in the WHERE clause. (Bug #16311231)
A Valgrind failure could occur if a CREATE USER statement was logged to the general query log and the old_passwords system variable was set to 2. (Bug #16300620)
For debug builds, checking of password constraints could raise an assertion for statements that updated passwords. (Bug #16289303)
Conversion of numeric values to BIT could yield unexpected results. (Bug #16271540)
Fixed warnings when compiling with XCode 4.6. Fixed warnings when compiling when the _XOPEN_SOURCE or isoctal macro was already defined in the environment. (Bug #16265300, Bug #60911, Bug #12407384)
In the range optimizer, an index merge failure could cause a server exit. (Bug #16241773)
For upgrade operations, RPM packages produced unnecessary errors about being unable to access .err files. (Bug #16235828)
Queries using range predicates that were evaluated using the LooseScan semijoin strategy could return duplicate rows. (Bug #16221623)

References: This issue is a regression of: Bug #14728469.
Certain legal HAVING clauses were rejected as invalid. (Bug #16221433)
yaSSL did not perform proper padding checks, but instead examined only the last byte of cleartext and used it to determine how many bytes to remove. (Bug #16218104)
The Performance Schema could return incorrect values for the PROCESSLIST_INFO column of the threads table. (Bug #16215165)
mysql_config --libs displayed incorrect output. (Bug #16200717)
Invocation of the range optimizer for a NULL select caused the server to exit. (Bug #16192219)
For debug builds, the server could exit due to incorrect calculation of applicable indexes for a join that involved const tables. (Bug #16165832)
For a CREATE TABLE (... col_name TIMESTAMP DEFAULT CURRENT_TIMESTAMP ...) ... SELECT statement for which the SELECT did not provide a value for the TIMESTAMP column, that column was set to '0000-00-00 00:00:00', not the current timestamp. (Bug #16163936)
Using GROUP BY WITH ROLLUP in a prepared statement could cause the server to exit. (Bug #16163596)
With the thread pool plugin enabled, large numbers of connections could lead to a Valgrind panic or failure of clients to be able to connect. (Bug #16088658, Bug #16196591)
Performance Schema instrumentation was missing for slave worker threads. (Bug #16083949)
The server executed EXPLAIN FORMAT=JSON for some malformed queries improperly. (Bug #16078557)
If the error for a failed CACHE INDEX statement index within a stored program was processed by a condition handler, a malformed packet and “Command out of sync” error occurred. (Bug #16076180)
Setting the slave_rows_search_algorithms system variable to an inappropriate value could cause the server to exit. (Bug #16074161)
SET PASSWORD and GRANT ... IDENTIFIED BY have no effect on the password of a user who is authenticated using an authentication plugin that accesses passwords stored externally to the mysql.user table. But attempts to change the password of such a user produced no warning, leading to the impression that the password had been changed when it was not. Now MySQL issues an ER_SET_PASSWORD_AUTH_PLUGIN warning to indicate that the attempt was ignored. (Bug #16072004)
Directory name manipulation could result in stack overflow on OS X and Windows. (Bug #16066243)
References to the unused SIGNAL_WITH_VIO_SHUTDOWN macro in the CMake files were removed. (Bug #16066150)
The initial test database contained a dummy.bak file that prevented DROP DATABASE from working. This file is no longer included. Also, a db.opt file is now included that contains these lines:
```
default-character-set=latin1
default-collation=latin1_swedish_ci
```
(Bug #16062056)
Issuing a PREPARE statement using certain combinations of stored functions and user variables caused the server to exit. (Bug #16056537)
Setting a system variable to DEFAULT could cause the server to exit. (Bug #16044655)
For debug builds, if the server was started with binary logging disabled, executing SHOW RELAYLOG EVENTS from within a stored procedure raised an assertion. (Bug #16043173)
The query parser leaked memory for some syntax errors. (Bug #16040022)
During shutdown, the server could attempt to lock an uninitialized mutex. (Bug #16016493)
The --default-authentication-plugin option permitted invalid plugin values, and did not always set the old_passwords system variable to a value appropriate for the named plugin. (Bug #16014394)
Instances of #ifdef WITH_MYISAMMRG_STORAGE_ENGINE and #ifdef WITH_CSV_STORAGE_ENGINE in the server source code were removed because the CSV and MERGE storage engine plugins are mandatory. (Bug #15997345)
The --character-set-server option could set connection character set system variables to values such as ucs2 that are not permitted. (Bug #15985752, Bug #23303391)
For debug builds, executing a statement within a trigger or stored function that caused an implicit commit raised an assertion. (Bug #15985318)
Under some circumstances, mysql --secure-auth permitted passwords to be sent to the server using the old (pre-4.1) hashing format. (Bug #15977433)
A mysys library string-formatting routine could mishandle width specifiers. (Bug #15960005)
Table creation operations added entries to the file_instances Performance Schema table, but these were not always removed for table drop operations. (Bug #15927620)
With index condition pushdown enabled, queries for which the pushed-down condition contained no columns in the used index could be slow. (Bug #15896009)
A query with an EXISTS/IN/ALL/ANY subquery with an ORDER BY clause ordering by an outer column of type BLOB that is not in the select list caused an assertion to fire. (Bug #15875919)

References: See also: Bug #14728142.
In special cases, the optimizer did not consider indexes that were applicable to query processing, resulting in potentially suboptimal execution and incorrect EXPLAIN output. (Bug #15849135, Bug #16094171)
Queries in the query cache involving a given table were incorrectly invalidated if a TEMPORARY table of the same name was dropped. (Bug #14839743)
The optimizer could return nonmatching records for queries that used ref access on string data types. (Bug #14826522)

References: See also: Bug #14682735.
Failure of CREATE SERVER due to a missing or read-only mysql.servers table resulted in a memory leak. (Bug #14781478)
Table names can be up to 64 characters, but the message string for the ER_TABLE_NEEDS_REBUILD and ER_TABLE_NEEDS_UPGRADE errors were truncating names longer than 32 characters. (Bug #14753226)
Enabling the query cache during high client contention could cause the server to exit. (Bug #14727815)
Enabling the slow query log at runtime when access permissions on the log file prevented the server from writing to it caused the server to exit. (Bug #14711347)
If the optimizer calculated a row count of zero for the inner table of an outer join, it could not determine proper ordering for the following tables. (Bug #14628746)
The server sometimes failed to respect MAX_CONNECTIONS_PER_HOUR limits on user connections. (Bug #14627287)
The server could access the DEBUG_SYNC facility while closing temporary tables during connection shutdown, after the facility had been cleaned up, leading to an assertion being raised. (Bug #14626800)
The optimizer could return incorrect results after transforming an IN subquery with aggregate functions to an EXISTS subquery. (Bug #14586710)
Table removal could fail and cause the server to exit for very long file names. (Bug #14581920)
When a client program loses the connection to the MySQL server or if the server begins a shutdown after the client has executed mysql_stmt_prepare(), the next mysql_stmt_prepare() returns an error (as expected) but subsequent mysql_stmt_execute() calls crash the client. (Bug #14553380)
Previously, if multiple --login-path options were given, mysql_config_editor ignored all but the last one. Now multiple --login-path options result in an error. (Bug #14551712)
If MySQL server was started with options to enable the general query log or slow query log, but access permissions on the log file prevented the server from writing to it, the server started with an error message indicating that logging was off and that the server needed to be restarted after the problem was corrected. This was incorrect because it is also possible to set the logging variables again at runtime (without a restart) after correcting the problem. The error message now indicates this possibility. (Bug #14512467)
For debug builds, creating a TEMPORARY table inside a trigger caused the server to exit. (Bug #14493938)
SHOW COLUMNS on a view defined as a UNION of Geometry columns could cause the server to exit. (Bug #14362617)
The sha256_password_private_key_path and sha256_password_public_key_path system variables indicate key files for the sha256_password authentication plugin, but the server failed to properly check whether the key files were valid. Now in the event that either key file is invalid, the server logs an error and exits. (Bug #14360513)
SET var_name = VALUES(col_name) could cause the server to exit. This syntax is now prohibited because in SET context there is no column name and the statement returns ER_BAD_FIELD_ERROR. (Bug #14211565)
The COM_CHANGE_USER command in the client/server protocol did not properly use the character set number in the command packet, leading to incorrect character set conversion of other values in the packet. (Bug #14163155)
If the server was started with --skip-grant-tables, the CREATE EVENT and ALTER EVENT statements resulted in a memory leak. (Bug #14059662)
Invoking the FORMAT() function with a locale and a very large number could cause the server to exit. (Bug #14040155)
For debug builds, improper handling for AUTO_INCREMENT value overflow could cause the server to exit. (Bug #13875572)
Certain plugin-related conditions can make a user account unusable:
- The account requires an authentication plugin that is not loaded.
- The account requires the sha256_password authentication plugin but the server was started with neither SSL nor RSA enabled as required by this plugin.
The server now checks those conditions by default and produces warnings for unusable accounts. This checking slows down server initialization and FLUSH PRIVILEGES, so it is made optional by means of the new validate_user_plugins system variable. This variable is enabled by default, but if you do not require the additional checking, you can disable it at startup to avoid the performance decrement. (Bug #13010061, Bug #14506305)
Passing an unknown time zone specification to CONVERT_TZ() resulted in a memory leak. (Bug #12347040)
The obsolete linuxthreads.txt and glibc-2.2.5.patch files in the Docs directory of MySQL distributions have been removed. (Bug #11766326)
The server could exit if built to permit a maximum number of indexes per table larger than 64.

In the course of fixing this problem, a -DMAX_INDEXES=N CMake option was added to permit building the server to support a larger maximum number of indexes per table. The default is 64. The maximum is 255. Values smaller than 64 are ignored and the default of 64 is used. (Bug #11761614)
mysql_install_db did not escape '_' in the host name for statements written to the grant tables. (Bug #11746817)
With explicit_defaults_for_timestamp enabled, inserting NULL into a TIMESTAMP NOT NULL column now produces an error (as it already did for other NOT NULL data types), instead of inserting the current timestamp. (Bug #68472, Bug #16394472)
Handling of SQL_CALC_FOUND_ROWS in combination with ORDER BY and LIMIT could lead to incorrect results for FOUND_ROWS(). (Bug #68458, Bug #16383173)
If INET6_NTOA() or INET6_ATON() returned NULL for a row in a result set, following rows also returned NULL. (Bug #68454, Bug #16373973)
A statement with an aggregated, nongrouped outer query and an aggregated, nongrouped subquery in the SELECT list could return incorrect results. (Bug #68372, Bug #16325175)
Adding an ORDER BY clause following an IN subquery could cause duplicate rows to be returned. (Bug #68330, Bug #16308085)
If the server was started with --skip-grant-tables, ALTER USER ... PASSWORD EXPIRE caused the server to exit. (Bug #68300, Bug #16295905)
Configuring with -DWITH_SSL=/path/to/openssl resulted in link errors due to selection of the incorrect libcrypto. (Bug #68277, Bug #16284051)
If mysql is built with the bundled libedit library, the library is built as static code, to avoid linking to a different dynamic version at runtime. Dynamic linking could result in use of a different, incompatible version and a segmentation fault. (Bug #68231, Bug #16296509)
Some table I/O performed by the server when calling a storage engine were missing from the statistics collected by the Performance Schema. (Bug #68180, Bug #16222630)
The Perl version of mysql_install_db mishandled some error messages. (Bug #68118, Bug #16197542)
For arguments with fractional seconds greater than six decimals, SEC_TO_TIME() truncated, rather than rounding as it should have. (Bug #68061, Bug #16093024)
Queries with many values in a IN() clause were slow due to inclusion of debugging code in non-debugging builds. (Bug #68046, Bug #16078212)

References: See also: Bug #58731, Bug #11765737.
ALTER TABLE tbl_name ADD COLUMN col_name TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP inserted 0000-00-00 00:00:00 rather than the current timestamp if the alteration was done in place rather than by making a table copy. (Bug #68040, Bug #16076089)
mysqld_safe used the nonportable -e test construct. (Bug #67976, Bug #16046140)
The server did not enforce the port or report_port upper limit of 65,535 and truncated larger values. (Bug #67956, Bug #16035522)
Nonspatial indexes only support exact-match lookups for spatial columns, but the optimizer incorrectly used range access in some cases, leading to incorrect results. (Bug #67889, Bug #15993693)
For EXPLAIN DELETE and EXPLAIN UPDATE the possible_keys column listed all indexes, not just the applicable indexes. (Bug #67830, Bug #15972078)
SLEEP() produced no warning or error for NULL or negative arguments. Now it produces a warning, or an error in strict SQL mode. (Bug #67548, Bug #15859462)
Attempts to create a trigger for which a trigger with the same action time and event already existed resulted in an ER_NOT_SUPPORTED_YET error rather than an ER_TRG_ALREADY_EXISTS error. (Bug #67357, Bug #14801721)
If a table had rows in the INFORMATION_SCHEMA.INNODB_CMP_PER_INDEX table, dropping the table did not remove those rows. (Bug #67283, Bug #14779330)
MySQL failed to build if configured with WITH_LIBWRAP enabled. (Bug #67018, Bug #16342793)
If one thread was rebuilding a result for the query cache, other threads in the middle of using the previous result could fail to discard the old result properly. For debug builds, this raised an assertion. (Bug #66781, Bug #14631798)
CMake did not check whether the system zlib had certain functions required for MySQL, resulting in build errors. Now it checks and falls back to the bundled zlib if the functions are missing. (Bug #65856, Bug #14300733)
If a dump file contained a view with one character set and collation defined on a view with a different character set and collation, attempts to restore the dump file failed with an “illegal mix of collations” error. (Bug #65382, Bug #14117025)
The SQL_NO_CACHE keyword is supposed to prevent the server from checking the query cache to see whether the query result is already cached, and to prevent it from caching the query result. However, the query cache check was suppressed only if SQL_NO_CACHE was preceded and followed by space characters. (For example, the server checked the cache if the keyword was followed by a newline.) Now the parser requires that the preceding and following characters be whitespace characters, not spaces. (Bug #64164, Bug #13641256)
If the server was started without a --datadir option, SHOW VARIABLES could show an empty value for the datadir system variable. (Bug #60995, Bug #12546953)
When a view definition contained a special character in the SEPARATOR clause of the GROUP_CONCAT() aggregate function, mysqldump created an invalid view definition that produced an error when the dump file was reloaded. (Bug #60920, Bug #12395512)
For debug builds, some queries with SELECT ... FROM DUAL nested subqueries raised an assertion. (Bug #60305, Bug #11827369)
The --log-slow-admin-statements and --log-slow-slave-statements command options now are exposed at runtime as the log_slow_admin_statements and log_slow_slave_statements system variables. Their values can be examined using SHOW VARIABLES. The variables are dynamic, so their values can be set at runtime. (The options were actually replaced by the system variables, but as system variables can be set at server startup, no option functionality is lost.) (Bug #59860, Bug #11766693)
Source code in the mysys library for the my_malloc_lock and my_free_lock memory-locking APIs was never used and has been removed. (Bug #54662, Bug #11762107)
If the server failed to read errmsg.sys, it could exit with a segmentation fault. (Bug #53393, Bug #11760944)
UNION ALL on BLOB columns could produce incorrect results. (Bug #50136, Bug #11758009)
An out-of-memory condition could occur while handling an out-of-memory error, leading to recursion in error handling. (Bug #49514, Bug #11757464)
The REPLACE() function produced incorrect results when a user variable was supplied as an argument and the operation was performed on multiple rows. (Bug #49271, Bug #11757250)
UNION type conversion could incorrectly turn unsigned values into signed values. (Bug #49003, Bug #11757005)
If XA support was activated by multiple storage engines, the server would exit. (Bug #47134, Bug #11755370)
Use of KILL to kill a statement in another session could in some cases cause that session to return an incorrect error code. (Bug #45679, Bug #11754124)
Setting max_connections to a value less than the current number of open connections caused the server to exit. (Bug #44100, Bug #11752803)
The optimizer used Loose Index Scan for some queries for which this access method is inapplicable. (Bug #42785, Bug #11751794)
View access in low memory conditions could raise a debugging assertion. (Bug #39307, Bug #11749556)
The output for SHOW CREATE VIEW could vary depending on the DEFINER account privileges. (Bug #34553, Bug #11747931)
If a column is declared as NOT NULL, it is not permitted to insert NULL into the column or update it to NULL. However, this constraint was enforced even if there was a BEFORE INSERT (or BEFORE UPDATE trigger) that set the column to a non-NULL value. Now the constraint is checked at the end of the statement, per the SQL standard. (Bug #6295, Bug #11744964, WL #6030)

PREV HOME UP NEXT