Documentation Home
MySQL 5.7 Release Notes
Related Documentation
MySQL 5.7 Reference Manual
Download these Release Notes
PDF (US Ltr) - 3.2Mb
PDF (A4) - 3.2Mb
MySQL 5.7 Release Notes  /  Changes in MySQL 5.7.6 (2015-03-09, Milestone 16)

Changes in MySQL 5.7.6 (2015-03-09, Milestone 16)

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.)

Account Management Notes

  • Incompatible Change: The CREATE USER and ALTER USER statements have additional account-management capabilities. Together, they now can be used to fully establish or modify authentication, SSL, and resource-limit properties, as well as manage password expiration and account locking and unlocking. For example, ALTER USER can assign passwords, and it can modify the authentication plugin for users, with no need for direct manipulation of the mysql.user table. For details, see CREATE USER Statement, and ALTER USER Statement.

    Account locking control is a new feature that permits administrators to completely disable an account from being used to connect to the server. Account locking state is recorded in the account_locked column of the mysql.user table. See Account Locking.

    A new statement, SHOW CREATE USER, shows the CREATE USER statement that creates the named user. The accompanying Com_show_create_user status variable indicates how many times the statement has been executed.

    A new system variable, log_backward_compatible_user_definitions, if enabled, causes the server to log CREATE USER, ALTER USER, and GRANT statements in backward-compatible (pre-5.7.6) fashion. Enabling this variable promotes compatibility for cross-version replication.

    The authentication_string column in the mysql.user table now stores credential information for all accounts. The Password column, previously used to store password hash values for accounts authenticated with the mysql_native_password and mysql_old_password plugins, is removed.

    If you upgrade to this MySQL release from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate the changes to the mysql database. mysql_upgrade moves Password column values to the authentication_string column and removes the Password column. For nonupgraded installations that have no account_locked column, the server treats all accounts as unlocked, and attempts to lock or unlock and account produce an error.

    The preceding changes make the following features obsolete. They are now deprecated and support for them will be removed in a future MySQL version:

    • Using GRANT to create users. Instead, use CREATE USER. Following this practice makes the NO_AUTO_CREATE_USER SQL mode immaterial for GRANT statements, so it too is deprecated.

    • Using GRANT to modify account properties other than privilege assignments. This includes authentication, SSL, and resource-limit properties. Instead, establish such properties at account-creation time with CREATE USER or modify them afterward with ALTER USER.

    • IDENTIFIED BY PASSWORD 'hash_string' syntax for CREATE USER and GRANT. Instead, use IDENTIFIED WITH auth_plugin AS 'hash_string' for CREATE USER and ALTER USER, where the 'hash_string' value is in a format compatible with the named plugin.

    • The PASSWORD() function is deprecated and should be avoided in any context. Thus, SET PASSWORD ... = PASSWORD('auth_string') syntax is also deprecated. SET PASSWORD ... = 'auth_string' syntax is not deprecated; nevertheless, ALTER USER is now the preferred statement for assigning passwords.

      Warning

      The changes in this release result in a semantic incompatibility for one SET PASSWORD syntax: 

      SET PASSWORD ... = 'literal string';

      Previously, SET PASSWORD interpreted the string as a password hash value to be stored directly. Now, SET PASSWORD interprets the string as a cleartext string and hashes it appropriately for the account authentication plugin before storing it.

      Note

      Any application that uses PASSWORD() to create hash values (a practice that has been discouraged for some time) should be modified to use a different hash-generation method. For suggestions, see the description of PASSWORD() in Encryption and Compression Functions.

    • The old_passwords system variable. Account authentication plugins can no longer be left unspecified in the mysql.user table, so any statement that assigns a password from a cleartext string can unambiguously determine the hashing method to use on the string before storing it in the mysql.user table. This renders old_passwords superflous.

    Note

    It is a known issue in this release that the following SET PASSWORD syntax produces an error: 

    SET PASSWORD ... = PASSWORD('auth_string');

    That syntax was to be deprecated, not removed. It will be restored in the next release, but generate a warning due to its deprecated status. These alternatives are available, the first of which is the preferred form: 

    ALTER USER ... IDENTIFIED BY 'auth_string';
SET PASSWORD ... = 'auth_string';

    The change in mysql.user table structure has compatibility implications for upgrading and downgrading:

    • You can perform a binary (in-place) upgrade to MySQL 5.7.6 or later and run mysql_upgrade to migrate the Password column contents to the authentication_string column.

    • If you plan to upgrade by loading a mysqldump dump file from an older (pre-5.7.6) MySQL installation, you must observe these conditions for the mysqldump command used to generate the file:

      Load the pre-5.7.6 dump file into the 5.7.6 server before running mysql_upgrade.

    • Because the Password column is gone in 5.7.6 and up, downgrading to a version older than 5.7.6 requires a special procedure. See Downgrade Notes.

    (WL #6054, WL #6409)

    References: See also: Bug #67449, Bug #14845612, Bug #18140348.

Compilation Notes

  • The minimum version of the Boost library for server builds is now 1.57.0. (Bug #74666, Bug #19940297, Bug #73432, Bug #19320102)

  • Work was done to clean up the source code base, including: Removing unneeded CMake checks; removing unused macros from source files; reorganizing header files to reduce the number of dependencies and make them more modular, removing function declarations without definitions, replacing locally written functions with equivalent functions from industry-standard libraries.

Configuration Notes

  • mysqld now supports a --daemonize option that causes it to run as a traditional, forking daemon. This permits the server to work with operating systems that use systemd for process control. Advantages include automatic restarts after failure, handling of the user and group used to run the daemon, resource control, and temporary-file cleanup.

    The new WITH_SYSTEMD CMake option, when enabled, causes installation of systemd support files. In addition, scripts such as mysqld_safe and the System V initialization script are not installed. On platforms where systemd is not available, enabling WITH_SYSTEMD results in an error from CMake. When WITH_SYSTEMD is enabled, the new SYSTEMD_SERVICE_NAME and SYSTEMD_PID_DIR options may also be used to specify the MySQL service name and directory in which the server creates the PID file, respectively.

    Support files for systemd are installed when you install MySQL using an RPM distribution for these Linux platforms:

    • Red Hat Enterprise Linux 7; Oracle Linux 7; CentOS 7

    • SUSE Linux Enterprise Server 12

    • Fedora 20, 21

    You also obtain systemd support by installing from a source distribution that is configured with the -DWITH_SYSTEMD=1 CMake option.

    To provide better information to management processes, the server now returns one of the exit codes described in the following list. The phrase in parentheses indicates the action taken by systemd in response to the code.

    • 0 = successful termination (no restart done)

    • 1 = unsuccessful termination (no restart done)

    • 2 = unsuccessful termination (restart done)

    Note

    Any management script written for older servers should be revised to handle three exit values if it checks only for 1 as a failure exit value.

    For more information, see Managing MySQL Server with systemd. That section also includes information about specifying options previously specified in [mysqld_safe] option groups. Because mysqld_safe is not installed when systemd is used, such options must be specified another way. (WL #7895)

Deprecation and Removal Notes

  • Replication: The variable binlogging_impossible_mode was renamed to binlog_error_action. (Bug #19507567)

  • Replication: The global scope for the sql_log_bin system variable has been deprecated, and this variable can now be set with session scope only. The statement SET GLOBAL SQL_LOG_BIN now produces an error. It remains possible to read the global value of sql_log_bin, but doing so produces a warning. You should act now to remove from your applications any dependencies on reading this value; the global scope sql_log_bin is removed in MySQL 8.0. (Bug #67433, Bug #15868071)

  • For client programs, --secure-auth is now deprecated and --skip-secure=auth is illegal, but use of --skip-secure-auth resulted in a warning followed by the help message rather than an error. (Bug #19438612)

  • OLD_PASSWORD() is deprecated, but no warning was produced when it was invoked. (Bug #73376, Bug #19285177)

  • ALTER TABLE did not take advantage of fast alterations that might otherwise apply to the operation to be performed, if the table contained temporal columns found to be in pre-5.6.4 format (TIME, DATETIME, and TIMESTAMP columns without support for fractional seconds precision). Instead, it upgraded the table by rebuilding it. Two new system variables enable control over upgrading such columns and provide information about them:

    • avoid_temporal_upgrade controls whether ALTER TABLE implicitly upgrades temporal columns found to be in pre-5.6.4 format. This variable is disabled by default. Enabling it causes ALTER TABLE not to rebuild temporal columns and thereby be able to take advantage of possible fast alterations.

    • show_old_temporals controls whether SHOW CREATE TABLE output includes comments to flag temporal columns found to be in pre-5.6.4 format. Output for the COLUMN_TYPE column of the INFORMATION_SCHEMA.COLUMNS table is affected similarly. This variable is disabled by default.

    Both variables are deprecated and will be removed in a future MySQL version. (Bug #72997, Bug #18985760)

  • The following items are deprecated and will be removed in a future MySQL version. Where alternatives are shown, applications should be updated to use them.

    • The ENCRYPT(), DES_ENCRYPT(), and DES_DECRYPT() functions, the --des-key-file option, the have_crypt system variable, the DES_KEY_FILE option for the FLUSH statement, and the HAVE_CRYPT CMake option. For ENCRYPT(), consider using SHA2() instead for one-way hashing. For the others, consider using AES_ENCRYPT() and AES_DECRYPT() instead.

    • The sync_frm system variable. This variable will be removed when .frm files become obsolete.

    • The global character_set_database and collation_database system variables are deprecated and will be removed in a future MySQL version.

      Assigning a value to the session character_set_database and collation_database system variables is deprecated and assignments produce a warning. The session variables will become read only in a future MySQL version and assignments will produce an error. It will remain possible to access the session variables to determine the database character set and collation for the default database.

    • Conversion of pre-MySQL 5.1 database names containing special characters to 5.1 format with the addition of a #mysql50# prefix. (For information about these conversions, see Mapping of Identifiers to File Names.) Because such conversions now are deprecated, the --fix-db-names and --fix-table-names options for mysqlcheck and the UPGRADE DATA DIRECTORY NAME clause for the ALTER DATABASE statement are also deprecated.

      Upgrades are supported only from one major version to another (for example, 5.0 to 5.1, or 5.1 to 5.5), so there should be little remaining need for conversion of older 5.0 database names to current versions of MySQL. As a workaround, upgrade a MySQL 5.0 installation to MySQL 5.1 before upgrading to a more recent release.

    (WL #3811, WL #8126, WL #8186, WL #8216)

Generated Columns

  • MySQL now supports the specification of generated columns in CREATE TABLE and ALTER TABLE statements. Values of a generated column are computed from an expression included in the column definition. Generated columns can be virtual (computed “on the fly” when rows are read) or stored (computed when rows are inserted or updated). The INFORMATION_SCHEMA.COLUMNS table shows information about generated columns.

    Uses for generated columns include simplifying queries when applications select from a table using a complex expression, simulating functional indexes, or substituting for views. For more information, see CREATE TABLE and Generated Columns. (WL #411)

Installation Notes

  • The mysqld server and mysql_upgrade utility have been modified to make binary (in-place) upgrades from MySQL 5.6 easier without requiring the server to be started with special options. The server checks whether the system tables are from a MySQL version older than 5.7 (that is, whether the mysql.user table has a Password column). If so, it permits connections by users who have an empty authentication plugin in their mysql.user account row, as long as they have a Password value that is empty (no password) or a valid native (41-character) password hash.

    This means that you can connect as root and upgrade your system tables even with an older mysql.user table for which root has no authentication plugin named. In particular, you can run mysql_upgrade, connecting as root, with no need to start the server with any special options. Previously, if the root account had an empty plugin value, a procedure involving starting the server with --skip-grant-tables and multiple restarts was required. The procedure now is simpler.

    1. Stop the old (MySQL 5.6) server

    2. Upgrade the MySQL binaries in place (replace the old binaries with the new ones)

    3. Start the MySQL 5.7 server normally (no special options)

    4. Run mysql_upgrade to upgrade the system tables

    5. Restart the MySQL 5.7 server

    (WL #8350)

  • Previously, for a new MySQL installation on Unix and Unix-like systems, initialization of the data directory (including the tables in the mysql system database) was done using mysql_install_db. On Windows, MySQL distributions included a data directory with prebuilt tables in the mysql database.

    mysql_install_db functionality now has been integrated into the MySQL server, mysqld. To use this capability to initialize a MySQL installation, if you previously invoked mysql_install_db manually, invoke mysqld with the --initialize or --initialize-insecure option, depending on whether you want the server to generate a random password for the initial 'root'@'localhost' account.

    As a result of this change, mysql_install_db is deprecated, as is the special --bootstrap option that mysql_install_db passes to mysqld. These will be removed in a future MySQL version. Also, the $HOME/.mysql_secret file written by mysql_install_db is no longer needed. If it is present on your system, you can remove it.

    Initializing a MySQL installation using mysqld works on all platforms, including Windows. In particular, it is possible to initialize a Windows installation without the set of prebuilt tables for the mysql database. (However, it is unnecessary to do so for this release because Windows distributions still include the pre-built tables.)

    For more information, see Initializing the Data Directory. (WL #7307)

Optimizer Notes

  • To handle a derived table (subquery in the FROM clause) or view reference, the optimizer can materialize the derived table or view reference to an internal temporary table or merge it into the outer query block. Previously, derived tables were always materialized, whereas equivalent view references were sometimes materialized and sometimes merged. This inconsistent treatment of equivalent queries could lead to performance problems: Unnecessary derived table materialization takes time and prevents the optimizer from pushing down conditions to derived tables.

    The optimizer now handles derived tables in consistent fashion; that is, the same as view references. This better avoids unnecessary materialization and enables use of pushed-down conditions that produce more efficient execution plans. For an example, see Optimizing Subqueries with Materialization.

    The optimizer also better handles propagation of an ORDER BY clause in a derived table or view reference to the outer query block, doing so only when this makes sense. Previously, the optimizer always propagated ORDER BY, even if it was irrelevant or resulted in an invalid query.

    For statements such as DELETE or UPDATE that modify tables, using the merge strategy for a derived table that previously was materialized can result in an ER_UPDATE_TABLE_USED error: 

    mysql> DELETE FROM t1
    -> WHERE id IN (SELECT id
    ->              FROM (SELECT t1.id
    ->                    FROM t1 INNER JOIN t2 USING (id)
    ->                    WHERE t2.status = 0) AS t);
ERROR 1093 (HY000): You can't specify target table 't1'
for update in FROM clause

    The error occurs when merging a derived table into the outer query block results in a statement that both selects from and modifies a table. (Materialization does not cause the problem because, in effect, it converts the derived table to a separate table.) To avoid this error, disable the derived_merge flag of the optimizer_switch system variable before executing the statement: 

    mysql> SET optimizer_switch = 'derived_merge=off';

    The derived_merge flag controls whether the optimizer attempts to merge derived tables and view references into the outer query block, assuming that no other rule prevents merging. By default, the flag is on to enable merging. Setting the flag to off prevents merging and avoids the error just described. (Other workarounds include using SELECT DISTINCT or LIMIT in the subquery, although these are not as explicit in their effect on materialization.) If an ER_UPDATE_TABLE_USED error occurs for a view reference that uses an expression equivalent to the subquery, adding ALGORITHM=TEMPTABLE to the view definition prevents merging and takes precedence over the current derived_merge value.

    For more information, see Optimizing Derived Tables and View References with Merging or Materialization. (WL #5275)

    References: See also: Bug #20073366, Bug #59203, Bug #11766159.

Packaging Notes

  • Microsoft Windows: For Windows, the noinstall Zip archive was split into two separate Zip archives. The MySQL test suite, MySQL benchmark suite, and debugging binaries/information components (including PDB files) were moved into their own Zip archive named mysql-VERSION-winx64-debug-test.zip for 64-bit and mysql-VERSION-win32-debug-test.zip for 32-bit. This change was made to reduce the file size of the more common download.

  • Packaging scripts such as those included in RPM or Debian packages have been modified per the principle that files installed from MySQL distributions should have the most restrictive permissions possible. In the following description, assume that the account used to administer MySQL has owner (user) = mysql, group = mysql.

    • Installers that create the mysql account do so with a shell of /bin/false to prevent direct login to the account.

    • The data directory and its contents are owned by and accessible only to owner/group mysql/mysql, with permissions of 750 for directories, 755 for executable files, 640 for other files.

    • Others files (including executables and libraries) have owner/group of root/root, with these permissions:

      • Executables: 755

      • Man pages, character set files, header files, test suite files: 644

      • Library files: Conventions appropriate for the host system

    Packaging scripts that perform the preceding actions for installation also perform them for upgrades, with the exceptions that if the mysql account exists, it is left unchanged, and if the data directory exists, its permissions and ownership are left unchanged. (WL #5608, WL #8129)

Performance Schema Notes

  • The Performance Schema incorporates these changes:

    • The Performance Schema now allocates memory incrementally, scaling its memory use to actual server load, instead of allocating all the memory it needs during server startup. Consequently, configuration of the Performance Schema is easier; most sizing parameters need not be set at all. A server that handles a very low load will consume less memory without requiring explicit configuration to do so.

      These system variables are autoscaled: 

      performance_schema_accounts_size
performance_schema_hosts_size
performance_schema_max_cond_instances
performance_schema_max_file_instances
performance_schema_max_index_stat
performance_schema_max_metadata_locks
performance_schema_max_mutex_instances
performance_schema_max_prepared_statements_instances
performance_schema_max_program_instances
performance_schema_max_rwlock_instances
performance_schema_max_socket_instances
performance_schema_max_table_handles
performance_schema_max_table_instances
performance_schema_max_table_lock_stat
performance_schema_max_thread_instances
performance_schema_users_size

      There are new instruments named with the prefix memory/performance_schema/ that expose how much memory is allocated for internal buffers in the Performance Schema. These instruments are displayed in the memory_summary_global_by_event_name table.

      For more information about how Performance Schema allocates memory and how to assess the amount currently in use, see The Performance Schema Memory-Allocation Model.

    • Instrumentation for table indexes and table locks is more flexible and less memory intensive. For a table for which index and table lock instrumentation is disabled (as specified in the setup_objects table), the Performance Schema allocates no memory for statistics collection. For a table for which index and table lock instrumentation is enabled, memory allocation for statistics collection is deferred until the table begins to be used.

      Configuration for instrumentation of table indexes and table locks now is exposed explicitly:

      • The performance_schema_max_table_lock_stat and performance_schema_max_index_stat system variables configure how many indexes per table and how many table locks are subject to statistics collection. These variables are autoscaling by default, reducing memory allocation for MySQL installations where the default allocation was greater than necessary for a server's workload (for example, when databases contain large numbers of tables). They can be set at startup to place explicit limits on memory allocation.

      • The Performance_schema_table_lock_stat_lost and Performance_schema_index_stat_lost status variables enable assessing whether the corresponding system variable settings are so low as to result in loss of instrumentation.

    • System and status variable information is now available in Performance Schema tables:

      These Performance Schema tables contain information similar to that available from the SHOW VARIABLES and SHOW STATUS statements and the GLOBAL_VARIABLES, SESSION_VARIABLES, GLOBAL_STATUS, and SESSION_STATUS INFORMATION_SCHEMA tables.

      The Performance Schema tables offer these advantages:

      • By using the variables_by_thread and status_by_thread tables, it is possible to obtain session variables for any session, not just the current session. It is also possible to obtain only session variables, rather than a mix of session and global variables such as returned by SHOW SESSION VARIABLES and SHOW SESSION STATUS.

      • Requests for global variables produce only global variables, whereas for the SHOW GLOBAL STATUS statement and the GLOBAL_STATUS INFORMATION_SCHEMA table, requests produce not only global variables, but also session variables that have no global counterpart.

      • Access to the Performance Schema tables requires the SELECT privilege, whereas the SHOW statements and INFORMATION_SCHEMA tables do not.

      For more information, see Performance Schema System Variable Tables, Performance Schema Status Variable Tables, and Status Variable Summary Tables.

      The value of the new show_compatibility_56 system variable affects the output produced from and privileges required for system and status variable statements and tables. For details, see the description of that variable in Server System Variables.

      The INFORMATION_SCHEMA tables now are deprecated in preference to the Performance Schema tables and will be removed in a future MySQL version. For advice on migrating away from the INFORMATION_SCHEMA tables to the Performance Schema tables, see Migrating to Performance Schema System and Status Variable Tables.

      Note

      It is a known issue in this release that the session_variables and session_status tables do not fully reflect all variable values in effect for the current session; they include no rows for global variables that have no session counterpart. This is corrected in MySQL 5.7.8.

    • Previously, the Performance Schema enabled instrumentation for new foreground threads if there was a row in the setup_actors table that matched the thread user and host. Now, the setup_actors table has an ENABLED column that indicates whether or not to enable instrumentation for matching foreground threads. This permits instrumentation for matching threads to be disabled explicitly. For more information, see Pre-Filtering by Thread, The setup_actors Table, and The threads Table.

    • Two previously hardcoded limits on SQL statement handling are now configurable:

      • The maximum number of bytes from SQL statements to display in the SQL_TEXT column of statement event tables, such as events_statements_current.

      • The number of bytes available for computing statement digests. Statement digests appear in the DIGEST_TEXT column of statement event tables.

      Previously, both values were fixed at 1024. It is now possible to change them at server startup using the performance_schema_max_sql_text_length and max_digest_length system variables. (The name max_digest_length does not begin with performance_schema_ because statement digesting is now done at the SQL level even if the Performance Schema is disabled and is available to other aspects of server operation that could benefit from it. For example, query rewrite plugins now make use of statement digests, even if the Performance Schema is disabled.)

      The defaults remain at 1024, but the values can be reduced to use less memory or increased to permit longer statements to be distinguished for display and digesting purposes. Each variable has a range from 0 to 1024 × 1024.

      Any bytes in excess of performance_schema_max_sql_text_length are discarded and do not appear in the SQL_TEXT column. Statements differing only after that many initial bytes are indistinguishable in this column.

      Any bytes in excess of max_digest_length during digest computation do not factor into digest values. Statements differing only after that many bytes of parsed statement tokens produce the same digest and are aggregated for digest statistics.

      For applications that generate very long statements that differ only at the end, the ability to change max_digest_length variables enables computation of digests that distinguish statements that previously were aggregated to the same digest. Conversely, administrators can devote less server memory to digest storage by reducing the values of this variable. Administrators should keep in mind that larger values result in correspondingly increased memory requirements, particularly for workloads that involve large numbers of simultaneous sessions. (max_digest_length bytes are allocated per session.)

      For more information, see Performance Schema Statement Digests.

    If you upgrade to this MySQL release from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate these changes into the performance_schema database. (WL #6629, WL #7270, WL #7800, WL #7698, WL #7794)

    References: See also: Bug #71057, Bug #68514, Bug #16414081.

Plugin Notes

  • MySQL Server now supports query rewrite plugins:

    • A preparse query rewrite plugin enables rewriting of SQL statements arriving at the server before the server processes them. The plugin receives a statement string and may return a different string.

    • A postparse query rewrite plugin enables statement rewriting based on parse trees. The server parses each statement and passes its parse tree to the plugin, which may traverse the tree. The plugin can return the original tree to the server for further processing, or construct a different tree and return that instead.

    MySQL distributions now include a postparse query rewrite plugin named Rewriter. This plugin is rule based. You can add rows to its rules table to cause SELECT statement rewriting.

    One application of query rewrite plugins is to enable use of newer server capabilities with applications that might not be subject to modification. For example, the plugin can add optimizer hints to statements produced by an older application that cannot be changed.

    For more information, see Query Rewrite Plugins, and The Rewriter Query Rewrite Plugin.

    Thanks to Padraig O'Sullivan for a related code contribution. (WL #7589)

Security Notes

  • Incompatible Change: The secure_file_priv system variable is used to limit the effect of data import and export operations. The following changes have been made to how the server handles this variable:

    • secure_file_priv can be set to NULL to disable all import and export operations.

    • The server checks the value of secure_file_priv at startup and writes a warning to the error log if the value is insecure. A non-NULL value is considered insecure if it is empty, or the value is the data directory or a subdirectory of it, or a directory that is accessible by all users. If secure_file_priv is set to a nonexistent path, the server writes an error message to the error log and exits.

    • Previously, the secure_file_priv system variable was empty by default. Now the default value is platform specific and depends on the value of the INSTALL_LAYOUT CMake option, as shown in the following table.

      INSTALL_LAYOUT Value Default secure_file_priv Value
      STANDALONE, WIN empty
      DEB, RPM, SLES, SVR4 /var/lib/mysql-files
      Otherwise mysql-files under the CMAKE_INSTALL_PREFIX value

    • To specify the default secure_file_priv value explicitly if you are building from source, use the new INSTALL_SECURE_FILE_PRIVDIR CMake option.

    (Bug #24679907, Bug #24695274, Bug #24707666, WL #6782)

  • yaSSL was upgraded to version 2.3.7. (Bug #19695101, Bug #20201864)

  • Due to the LogJam issue (https://weakdh.org/), OpenSSL has changed the Diffie-Hellman key length parameters for openssl-1.0.1n and up. OpenSSL has provided a detailed explanation at http://openssl.org/news/secadv_20150611.txt. To adopt this change in MySQL, the key length used in vio/viosslfactories.c for creating Diffie-Hellman keys has been increased from 512 to 2,048 bits. (Bug #77275, Bug #21221862, Bug #18367167, Bug #21307471, Bug #21449838)

  • To make it easier to produce the files required to support encrypted connections using SSL and secure password exchange using RSA over unencrypted connections, MySQL distributions now include the mysql_ssl_rsa_setup utility. This utiliy uses the openssl command, so its use is contingent on having OpenSSL installed on your machine. When invoked, mysql_ssl_rsa_setup checks the data directory for SSL and RSA files and uses openssl to create them if they are missing. For more information, see mysql_ssl_rsa_setup — Create SSL/RSA Files.

    Autodiscovery of key and certificate files in the data directory at startup now applies to servers compiled using yaSSL. Previously, this applied only to servers compiled using OpenSSL. See Configuring MySQL to Use Encrypted Connections.

    If the server automatically enables encrypted connections, it writes a message to the error log. If the server finds that the CA certificate is self-signed, it writes a warning to the error log. (The certificate will be self-signed if created automatically by the server or manually using mysql_ssl_rsa_setup.) (WL #7706)

Spatial Data Support

Functionality Added or Changed

  • Incompatible Change; InnoDB: The MERGE_THRESHOLD value for index pages is now configurable using a COMMENT clause with CREATE TABLE, ALTER TABLE, and CREATE INDEX statements. If the page-full percentage for an index page falls below the MERGE_THRESHOLD value when a row is deleted or when a row is shortened by an UPDATE operation, InnoDB attempts to merge the index page with a neighboring index page. The default MERGE_THRESHOLD value is 50, which is the previously hard-coded value.

    This feature adds a MERGE_THRESHOLD column to the internal SYS_INDEXES table. SYS_INDEXES records for tables that were originally created in 5.7.5 or earlier do not include this column. Rebuilding or importing these tables after upgrading to MySQL 5.7.6 or later properly updates SYS_INDEXES records with the new MERGE_THRESHOLD column. Otherwise, TRUNCATE TABLE or ALTER TABLE ... RENAME INDEX operations followed by a server restart or a table reload causes errors. This bug is fixed in MySQL 5.7.8 (Bug #20882432).

    For more information, see Configuring the Merge Threshold for Index Pages. (WL #6747)

  • Incompatible Change: A new C API function, mysql_real_escape_string_quote(), has been implemented as a replacement for mysql_real_escape_string() because the latter function can fail to properly encode characters when the NO_BACKSLASH_ESCAPES SQL mode is enabled. In this case, mysql_real_escape_string() cannot escape quote characters except by doubling them, and to do this properly, it must know more information about the quoting context than is available. mysql_real_escape_string_quote() takes an extra argument for specifying the quoting context. For usage details, see mysql_real_escape_string_quote().

    Note

    Applications should be modified to use mysql_real_escape_string_quote(), instead of mysql_real_escape_string(), which now fails and produces an CR_INSECURE_API_ERR error if NO_BACKSLASH_ESCAPES is enabled.

    (WL #8077)

    References: See also: Bug #19211994.

  • InnoDB: All remaining code related to the innodb_file_io_threads system variable, which was removed in MySQL 5.5, was removed from the source code. (Bug #19843885, WL #7149)

  • InnoDB: InnoDB system tablespace data is now exposed in the INNODB_SYS_TABLESPACES and INNODB_SYS_DATAFILES Information Schema tables. (WL #6205)

  • InnoDB: To modularize and decouple the partitioning engine from the server code base, partitioning operations in the storage engine handler class were moved to a new partition_handler base class, which is now the interface for partitioning-specific storage engine functionality. (WL #4807)

  • InnoDB: InnoDB now supports the creation of general tablespaces using CREATE TABLESPACE syntax. 

    CREATE TABLESPACE `tablespace_name`
  ADD DATAFILE 'file_name.ibd'
  [FILE_BLOCK_SIZE = n]

    General tablespaces can be created outside of the MySQL data directory, are capable of holding multiple tables, and support tables of all row formats.

    Tables are added to a general tablespace using CREATE TABLE tbl_name ... TABLESPACE [=] tablespace_name or ALTER TABLE tbl_name TABLESPACE [=] tablespace_name syntax.

    For more information, see CREATE TABLESPACE Statement. (WL #6205)

  • InnoDB: InnoDB now supports native partitioning. Previously, InnoDB relied on the ha_partition handler, which creates a handler object for each partition. With native partitioning, a partitioned InnoDB table uses a single partition-aware handler object. This enhancement reduces the amount of memory required for partitioned InnoDB tables.

    The following changes accompany InnoDB native partitioning support:

    • Partition definition (.par) files are no longer created for partitioned InnoDB tables. Partition definitions are stored in the InnoDB internal data dictionary. Partition definition (.par) files continue to be used for partitioned MyISAM tables.

    • For partitioned InnoDB tables, FLUSH TABLES does not reset the “next” AUTO_INCREMENT value. Instead, the next AUTO_INCREMENT value is kept and used after the FLUSH TABLES operation. If the highest AUTO_INCREMENT value is deleted before a FLUSH TABLES operation, it is not reused afterwards.

    • Minor changes to statistics could result in changed execution plans.

    • The minimum number of rows estimated for a partitioned InnoDB table is 1 instead of 2.

    • The minimum number of rows estimated for range read on a partitioned InnoDB table index is 0 per partition instead of 1.

    • Instead of only including the largest partitions when calculating matching rows in an index range, all partitions in the read set (after pruning is completed) are included. As a result, statistics for matching index rows are more accurate, but time spent during the Optimizer phase may increase for tables with numerous partitions.

    (WL #6035)

  • InnoDB: The following buffer pool flushing-related enhancements are included in MySQL 5.7.6:

    • The adaptive flushing algorithm flushes all pages at the end of the flush list if there is a high distribution of pages associated with the oldest LSN.

    • Once redo space reaches 30% full, a pre-scan on buffer pool instances determines the oldest modified pages in each buffer pool instance. Based on this information, the adaptive flushing algorithm determines the number of pages to flush from each buffer pool instance during a single flush pass. This approach helps ensure that the oldest modified pages are flushed first.

    • On Linux platforms where it is possible and where the mysqld execution user is authorized, the setpriority() system call is used to give page_cleaner threads priority over other MySQL/InnoDB threads to help page flushing keep pace with the current workload. mysqld execution user authorization can be configured in /etc/security/limits.conf. Refer to your Linux operating system documentation for more information.

    • When the oldest modification LSN is close to the defined maximum (max_modified_age_sync), a synchronous preflush of buffer pool pages is initiated which may result in a “flush wait” scenario for user threads. To smooth throughput, user threads are only required to wait for a target LSN to be reached instead of waiting for an entire flushing batch to finish. User thread waits are reported as sync flush waits by the buffer_flush_sync_waits metric of the INFORMATION_SCHEMA.INNODB_METRICS table.

    • A block was added to prevent the log write mechanism from overwriting last checkpoint LSN.

    • A message is printed to the server error log if the innodb_io_capacity_max setting is too high.

    • New metrics for monitoring page_cleaner thread activity were added to the INNODB_METRICS table:

      • buffer_flush_adaptive_avg_pass: Number of adaptive flushes passed during the recent Avg period.

      • buffer_flush_adaptive_avg_time_est: Estimated time (ms) spent for adaptive flushing recently.

      • buffer_flush_adaptive_avg_time_slot: Avg time (ms) spent for adaptive flushing recently per slot.

      • buffer_flush_adaptive_avg_time_thread: Avg time (ms) spent for adaptive flushing recently per thread.

      • buffer_flush_avg_pass: Number of flushes passed during the recent Avg period.

      • buffer_flush_avg_time: Avg time (ms) spent for flushing recently.

      • buffer_flush_n_to_flush_by_age: Number of pages targeted by LSN Age for flushing.

      • buffer_LRU_batch_flush_avg_pass: Number of LRU batch flushes passed during the recent Avg period.

      • buffer_LRU_batch_flush_avg_time_est: Estimated time (ms) spent for LRU batch flushing recently.

      • buffer_LRU_batch_flush_avg_time_slot: Avg time (ms) spent for LRU batch flushing recently per slot.

      • buffer_LRU_batch_flush_avg_time_thread: Avg time (ms) spent for LRU batch flushing recently per thread.

      • buffer_LRU_get_free_loops: Total loops in LRU get free.

      • buffer_LRU_get_free_waits: Total sleep waits in LRU get free.

    (WL #7868)

  • InnoDB: The Performance Schema now instruments stage events for monitoring InnoDB ALTER TABLE and buffer pool load operations. The new stage events include:

    • stage/innodb/alter table (read PK and internal sort)

    • stage/innodb/alter table (merge sort)

    • stage/innodb/alter table (insert)

    • stage/innodb/alter table (flush)

    • stage/innodb/alter table (log apply index)

    • stage/innodb/alter table (log apply table)

    • stage/innodb/alter table (end)

    • stage/innodb/buffer pool load

    For more information, see InnoDB Integration with MySQL Performance Schema, and Saving and Restoring the Buffer Pool State. (WL #5889)

  • InnoDB: Replication-related support was added to InnoDB which enables prioritization of slave applier transactions over other transactions in deadlock scenarios. This transaction prioritization mechanism is reserved for future use. (WL #6835)

  • InnoDB: CHECK TABLE functionality was enhanced for InnoDB SPATIAL indexes. Previously, CHECK TABLE only performed minimal checks on InnoDB SPATIAL indexes. Enhanced functionality includes an R-tree validity check and a check to ensure that the R-tree row count matches the clustered index. (WL #7740)

  • InnoDB: The default setting for the internal_tmp_disk_storage_engine option, which defines the storage engine the server uses for on-disk internal temporary tables, is now INNODB. With this change, the Optimizer uses the InnoDB storage engine instead of MyISAM for internal temporary tables. For related information, see Internal Temporary Table Use in MySQL. (WL #6737)

  • InnoDB: InnoDB now supports 32KB and 64KB page sizes. For both page sizes, the maximum record size is 16KB. ROW_FORMAT=COMPRESSED is not supported for 32KB or 64KB page sizes. The extent size is 2MB for the 32KB page size, and 4MB for the 64MB page size. The innodb_log_buffer_size default value was increased from 8MB to 16MB to support the new page sizes. innodb_log_buffer_size should be set to a minimum of 16MB when using a 32KB or 64KB page size. (WL #5757)

  • InnoDB: To support future development, the code that initializes, validates and handles tablespace and table flags was refactored. Also, the fil_create_ibd_tablespace function was refactored, and some functions and variables related to single tablespaces were renamed. (WL #8109)

  • Replication: When using InnoDB with binary logging enabled, concurrent transactions written in the InnoDB redo log are now grouped together before synchronizing to disk when innodb_flush_log_at_trx_commit is set to 1, which reduces the amount of synchronization operations. This can lead to improved performance. (Bug #19424075)

  • Replication: There is now a Previous_gtids event in every binary log, regardless of the value of gtid_mode. In previous versions, it was only generated when gtid_mode=on. Similarly, there is now an Anonymous_gtid event before every transaction when gtid_mode=off. These changes ensure that similar per-transaction events are generated regardless of the type of binary logging in use. As well as enabling the newly added ability to change gtid_mode online, this also has a positive impact on the recovery of gtid_purged and gtid_executed. (WL #7592)

  • Replication: A new more general purpose parallelization algorithm is now used when slave_parallel_type=LOGICAL_CLOCK, replacing the previous algorithm that was limited to transactions on different databases. This improves throughput when transactions on the master do not depend on each other. Now even two concurrent transactions on a master can execute in parallel on a slave, if they hold all of their locks on the master. Additionally, transaction dependency is now tracked on the slave through extra fields added to replication transactions in the binary log. (WL #7165)

  • Replication: It is now possible to change replication mode without having to shut down the server or synchronize the topology. As part of this feature, the following changes have been made:

    For more information, see Changing Replication Modes on Online Servers (WL #7083)

  • Replication: MySQL Multi-Source Replication adds the ability to replicate from multiple masters to a slave. MySQL Multi-Source Replication topologies can be used to back up multiple servers to a single server, to merge table shards, and consolidate data from multiple servers to a single server. See MySQL Multi-Source Replication.

    As part of MySQL Multi-Source Replication, replication channels have been added. Replication channels enable a slave to open multiple connections to replicate from, with each channel being a connection to a master. To enable selection of particular channels, replication-related SQL statements now support an optional FOR CHANNEL channel clause. See Replication Channels. (WL #1697)

  • Group Replication: Added a number of features and enhancements relating to Performance Schema and Group Replication. These additions are listed here:

    (WL #6834, WL #6826, WL #7988, WL #8252, WL #6841)

  • Undocumented functions in the C client library are now hidden. This helps minimize namespace pollution, and permits linking for applications that require functions both from yaSSL (in the client library) and from OpenSSL. (Bug #20476596, Bug #18427840)

  • CMake support was updated to handle CMake version 3.1. (Bug #20344207)

  • Previously, debug builds on Windows were built with /Ob0, which disables function inlining. Builds now use /Ob1 to enable inlining. The new WIN_DEBUG_NO_INLINE CMake option can be used to control inlining. The default value is OFF (inlining enabled); if set to ON, inlining is disabled. (Bug #20316320)

  • The new -DWITH_UBSAN=ON CMake option enables the Undefined Behavior Sanitizer. This feature is supported by GCC 4.9 and up, and Clang 3.4 and up. (Bug #19587393)

  • The valid date range of the SSL certificates in mysql-test/std_data has been extended to the year 2029. (Bug #18366947)

  • Overhead was reduced for queries such as tested by the sysbench “order-by-range” test. (Bug #75390, Bug #20296891)

  • The mysql client program now supports \C in the prompt command to signify the current connection identifier. Thanks to Tsubasa Tanaka for the patch. (Bug #75242, Bug #20227145)

  • The server now includes its version number when it writes the initial “starting” message to the error log, to make it easier to tell which server instance error log output applies to. This value is the same as that available from the version system variable. (Bug #74917, Bug #20052694)

  • Previously, the auth_socket authentication plugin checked the socket user name only against the MySQL user name specified by the client program to the server. Now, if those names do not match, the plugin also checks whether the socket user name matches the name specified in the authentication_string column of the mysql.user table row. The plugin permits the connection for a match in either case. Thanks to Daniël van Eeden for the patch. (Bug #74586, Bug #20041925)

  • The libmysqlclient version number has been incremented to 20.0.0. (Bug #74206, Bug #19729266)

  • A new CMake option, WITH_MSCRT_DEBUG, is available to control Visual Studio CRT memory leak tracing. The default is OFF. (Bug #73064, Bug #19031370)

  • Beginning with MySQL 5.7.2, the server disables at startup any account that has no authentication plugin. The server now writes a more extensive message to the error log in this case to indicate how to reenable such accounts. (Bug #73026, Bug #19011337)

  • The minimum value of the stored_program_cache system variable has been changed from 256 to 16, to enable configuration of a smaller amount of memory devoted to the stored program cache. (Bug #72451, Bug #18661573)

  • The code in my_strnxfrm_simple() was suboptimal and was improved. Thanks to Alexey Kopytov for the patch. (Bug #68476, Bug #16403708)

  • The metadata locking subsystem (see Metadata Locking) has been extended to cover concurrent access to tablespaces. This includes DDL statements that explicitly affect tablespaces: ALTER TABLESPACE, CREATE TABLESPACE, and DROP TABLESPACE. It also includes DDL statements that affect tablespace contents: ALTER TABLE, CREATE INDEX, CREATE TABLE, DROP INDEX, DROP TABLE, LOCK TABLES, RENAME TABLE, and TRUNCATE TABLE. (WL #7957)

  • For queries that combine ORDER BY with LIMIT, the optimizer may switch to an index that applies to the ORDER BY. In some cases, the decision to switch was based on a heuristic rather than on cost. The optimizer now uniformly makes the decision whether to switch on a cost basis. This should result in better performanance when switching would cause a query to read an entire index or a large part of it to find qualifying rows. (WL #6986)

    References: See also: Bug #78993, Bug #22108385, Bug #73837, Bug #19579507, Bug #16522053.

  • Server and client errors are numbered in ranges beginning from 1000 and 2000, respectively. However, server error numbers are approaching 2000, leading to a potential conflict with client error numbers. To deal with this, server error numbers for MySQL 5.7 now have a range beginning with 3000. This is implemented by permitting multiple start-error-number N lines in sql/share/errmsg-utf8.txt, with each such line resetting the numbering to N. (WL #8206)

  • Refactoring within the optimizer resulted in the following improvements to EXPLAIN output:

    • Output that showed ORDER BY col_name for implicitly grouped queries no longer does so.

    • Output for INSERT statements involving partition pruning now shows only the partitions actually used, not all partitions in the table.

    • Output for UPDATE, INSERT, or DELETE statements no longer shows “Using join buffer” in cases when join buffering was not used.

    In addition, for killed queries where the previously returned error was “Unknown error”, the error is now “Query execution was interrupted”. (WL #7870)

    References: See also: Bug #70553, Bug #17575172.

  • MySQL now provides a built-in ngram full-text parser plugin that supports Chinese, Japanese, and Korean (CJK), and an installable MeCab full-text parser plugin for Japanese. The parser plugins can be used with InnoDB and MyISAM tables.

    The built-in MySQL full-text parser uses the white space between words as a delimiter to determine where words begin and end, which is a limitation of the built-in MySQL full-text parser for ideographic languages that do not use word delimiters. The addition of ngram and MeCab full-text parser plugins address this limitation.

    For more information see ngram Full-Text Parser, and MeCab Full-Text Parser Plugin. (WL #6607)

  • The plugin and servers tables in the mysql system database now are InnoDB (transactional) tables. Previously, these were MyISAM (nontransactional) tables.

    In consequence of this change, INSTALL PLUGIN and UNINSTALL PLUGIN are now included among the statements that cause an implicit commit (see Statements That Cause an Implicit Commit).

    If you upgrade to this MySQL release from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate these changes into the mysql database. (WL #7160)

  • The new session_track_gtids system variable configures a session tracker that captures GTIDs and returns them from the server to the client. From the C API, GTID information can be obtained by passing SESSION_TRACK_GTIDS as the type argument to the mysql_session_track_get_first() and mysql_session_track_get_next() functions. For more information, see Server Tracking of Client Session State. (WL #6128, WL #6972)

Bugs Fixed

  • Incompatible Change; InnoDB: If your system contains tablespace data files created prior to MySQL 5.1, read this note carefully before upgrading to MySQL 5.7.6.

    Tablespace data files created prior to MySQL 5.1 sometimes contain garbage FIL_PAGE_TYPE values in some pages. To address this issue, a new file page type constant (FIL_PAGE_TYPE_UNKNOWN) was added, and unknown FIL_PAGE_TYPE values are now reset to FIL_PAGE_TYPE_UNKNOWN.

    However, you may still encounter a failure when a non-index page that contains an invalid FIL_PAGE_INDEX or FIL_PAGE_RTREE value in the FIL_PAGE_TYPE field is written to disk. You can address the failure by modifying the data file to replace the invalid FIL_PAGE_TYPE values with FIL_PAGE_UNKNOWN. The error log message provides the tablespace ID and page number of the page with the invalid FIL_PAGE_TYPE value.

    Before MySQL 5.6, InnoDB page size is always 16384 bytes. FIL_PAGE_TYPE is defined as 24. So, if page number P of a tablespace data file is affected, the data at byte offset 16384*P+24 should contain the bytes 0x45 0xbf (FIL_PAGE_INDEX) or 0x45 0xbe (FIL_PAGE_RTREE). Replace these bytes with 0x00 0x0d (FIL_PAGE_UNKNOWN).

    If the page contains the strings infimum and supremum at byte offset 99 or 101 (75 or 77 bytes after the start of the FIL_PAGE_TYPE), the page could be an index page, and there may be actual corruption.

    Warning

    Do not attempt to modify data files directly unless you know exactly what you are doing and fully understand the implications. Manually modifying the data file is no longer required in MySQL 5.7.7 with the fix for Bug #20691930.

    If FIL_PAGE_TYPE is reset to FIL_PAGE_TYPE_UNKNOWN in your pre-MySQL 5.5 data file, you may encounter a page corruption error when restarting the server. The error is due to a FIL_PAGE_TYPE field in the InnoDB page checksum that is still set to the previous FIL_PAGE_TYPE value. To address the error, rewrite the page checksum using the innochecksum tool. The patch for Bug #20691930 in MySQL 5.7.7 addresses this problem by recomputing the page checksum after resetting the FIL_PAGE_TYPE value. (Bug #17345513, Bug #17332603, Bug #19658698)

  • InnoDB; Microsoft Windows: On Windows, renaming a FULLTEXT search file name raised an assertion. (Bug #20001827)

  • InnoDB; Microsoft Windows: The logic used to select native asynchronous I/O (AIO) on Windows was simplified. All Windows versions supported by MySQL 5.7 now support native AIO. The logic required to handle older Windows versions that do not support native AIO was no longer necessary. (Bug #19803939)

  • InnoDB: Opening and closing of optimized temporary tables caused a negative table reference count in InnoDB Monitor output. (Bug #20608113)

  • InnoDB: A duplicate database page corruption error message was removed from buf0buf.cc. (Bug #20605167)

  • InnoDB: The NAME column of the INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO table was incorrectly declared as 192 characters wide. The correct length is 64 characters. (Bug #20512578)

  • InnoDB: A full-text phrase search returned an incorrect result. An empty string was handled incorrectly when tokenizing a newly inserted row. (Bug #20465273, Bug #75755)

  • InnoDB: A workaround introduced in MySQL 5.7.0, in the patch for Bug #14658648, was removed. The workaround allowed MySQL to disable the query cache during crash recovery. Inconsistent data could be produced during crash recovery if MySQL crashed while XA transactions were in a PREPARED state with the query cache enabled. The bug was fixed in MySQL 5.7.2 by the patch for Bug #16593427. (Bug #20461632)

  • InnoDB: In debug builds, assertion code related to buffer pool resizing caused a significant increase in Valgrind testing time. (Bug #20461123)

  • InnoDB: The use of change buffering for a spatial index raised an assertion. Change buffer flags should not be set for spatial indexes. (Bug #20452564, Bug #75718)

  • InnoDB: On ALTER TABLE ... IMPORT TABLESPACE, there was a missing dictionary unlock call on Out-Of-Memory(OOM) that could result in a failure when allocating memory for an .ibd file path string. (Bug #20430105)

  • InnoDB: An undefined reference error occurred when building MySQL with DWITH_EXTRA_CHARSETS=none. (Bug #20429800)

  • InnoDB: Optimizing a FULLTEXT index raised an assertion. The last optimized word of a FULLTEXT index is stored in the CONFIG table value column which is defined as CHAR(50). An assertion was raised when the last optimized word was greater than 50 characters in length. The CONFIG table value column is defined as CHAR(200) as of MySQL 5.6.24 and MySQL 5.7.6.

    If your innodb_ft_max_token_size setting is greater than 50, it is recommended that you recreate existing InnoDB FULLTEXT indexes after upgrading to MySQL 5.6.24 or MySQL 5.7.6 to avoid this issue. FULLTEXT indexes created after upgrading to MySQL 5.6.24 or MySQL 5.7.6 are unaffected. (Bug #20418326)

  • InnoDB: The innodb_optimize_point_storage option and related internal data types (DATA_POINT and DATA_VAR_POINT) were removed. (Bug #20415831)

  • InnoDB: fts_optimize_thread() set a NULL exit_event when the server started to shut down, and before fts_optimize_thread was started. (Bug #20389745)

  • InnoDB: The memcached process_arithmetic_command raised an assertion. The wrong error code was returned for a nonexistent decr key. (Bug #20386835)

  • InnoDB: The expiration time (exptime) defined using the memcached set command was ignored. InnoDB memcached set the expiration time to an interval value instead of a system time value. (Bug #20381342, Bug #70055)

  • InnoDB: A NaN value in the GIS-related mbr_join_square function raised an assertion. (Bug #20379160)

  • InnoDB: The innobase_close_thd function and related wrapper functions and pointers were removed. The functions and pointers were introduced with the InnoDB memcached plugin but never used. (Bug #20369370)

  • InnoDB: An assertion was raised when the full-text search fts_savepoint_release() function released a named transaction savepoint and all subsequent savepoints. Only the initial savepoint should be released. (Bug #20341916)

  • InnoDB: Table names were displayed inconsistently in diagnostic output for InnoDB tables that store persistent statistics. (Bug #20330831)

  • InnoDB: The INFORMATION_SCHEMA.TABLES UPDATE_TIME field, enabled for InnoDB tables in MySQL 5.7.2, was not updated for XA COMMIT of recovered transactions that were in XA PREPARE state. (Bug #20303205)

  • InnoDB: An incorrect expression was used in /storage/innobase/trx/trx0trx.cc. trx->lock.rec_pool.empty() was used instead of trx->lock.table_pool.empty(). (Bug #20294158, Bug #75373)

  • InnoDB: In /storage/innobase/handler/ha_innodb.cc, a va_end() was missing in returns that were added in MySQL 5.7.5. (Bug #20285744, Bug #75323)

  • InnoDB: A full-text search optimization operation raised an assertion. (Bug #20281800)

  • InnoDB: A tablespace export operation set the purge state to PURGE_STATE_STOP, but the purge thread did not check the purge state until the current purge operation was completed. In the case of a large history list, the tablespace export operation was delayed, waiting for the current purge operation to finish. The purge state is now checked with every purge batch. (Bug #20266847, Bug #75298)

  • InnoDB: When a page is read from disk, there is a check for pending insert buffer entries which involves acquiring a latch on the insert buffer page. If pending entries are found, they are merged. Because the change buffer is only applicable to B-tree secondary leaf pages in non-temporary tablespaces, insert buffer merge is not necessary for all page types. Using page_type, page_level, and tablespace type information from the page that is read from disk, insert buffer merge is now skipped for non-applicable page types. (Bug #20220909)

  • InnoDB: The name of the internal pseudo-tablespace that is created for the InnoDB redo log was changed from ib_logfile101 to innodb_redo_log. The new name aligns with other MySQL 5.7 internal tablespace names that use an “innodb_” prefix. (Bug #20204978)

  • InnoDB: An ALTER TABLE ... ADD INDEX operation raised an assertion due to assertion code that did not allow an online index status of ONLINE_INDEX_ABORTED_DROPPED. The assertion code was relaxed. (Bug #20198726)

  • InnoDB: Attempting to access the table name for a table that was NULL due to a prior inconsistency caused a crash in innobase_update_foreign_cache() when printing an error. (Bug #20146176)

  • InnoDB: An error occurred when the push_warning_printf function was invoked during server recovery. This function was previously used to print a warning message to the client. Also, current_thd was NULL when the server was restarted. (Bug #20144839)

  • InnoDB: The last flushing loop on shutdown did not call buf_flush_wait_LRU_batch_end(), resulting in an assertion failure. (Bug #20137435)

  • InnoDB: The dict_index_t::auto_gen_clust_index flag, which was used inconsistently and redundant, was removed. (Bug #20136192)

  • InnoDB: A memory access violation in fts_optimize_thread caused the server to halt. A table was freed but not removed from the full-text search optimize queue. (Bug #20125560)

  • InnoDB: An assertion was raised while updating statistics for referenced tables after a cascade update. (Bug #20125466)

  • InnoDB: A crash occurred in btr_cur_latch_leaves while performing a load operation. Checking the page state without latching the page caused an inconsistency. The page state should only be checked after the page is latched. (Bug #20111105, Bug #74596)

  • InnoDB: The INNODB_METRICS adaptive_hash_searches_btree counter failed to report counter data. (Bug #20080942, Bug #74511)

  • InnoDB: Due to a regression introduced in MySQL 5.6.20, mysqld stop did not stop the mysqld server process while the InnoDB memcached plugin was active. (Bug #20078646, Bug #74956)

    References: This issue is a regression of: Bug #18409840.

  • InnoDB: The commit_node member from the tab_node_t and ind_node_t query graph objects, used during table and index creation, were removed. The commit_node member was initialized but never used. Unused TABLE_COMMIT_WORK and INDEX_COMMIT_WORK execution steps were also removed. (Bug #20060218)

  • InnoDB: An ALTER TABLE ... RENAME failure on a table with a FULLTEXT index raised an assertion. (Bug #20043707)

  • InnoDB: A duplicate key error encountered during a REPLACE operation on a temporary table raised an assertion. (Bug #20040791)

  • InnoDB: An ALTER TABLE operation that changed the name of a foreign key column resulted in a failure when reloading the foreign key constraint. The previous column name remained in the data dictionary cache instead of being evicted. (Bug #20031243)

  • InnoDB: ALTER TABLE failed to check if the table is corrupted. An ALTER TABLE operation that affects InnoDB metadata should be refused if the clustered index is corrupted or the table is marked as corrupted. An ALTER TABLE operation should also be refused if the table is not rebuilt and a corrupted secondary index would remain after the ALTER TABLE operation. (Bug #20015132, Bug #74810)

  • InnoDB: A row update operation raised an assertion in row_upd_sec_index_entry(). In row_merge_read_clustered_index(), the cached spatial index was not inserted prior to the mini-transaction commit. Once the mini-transaction was committed, the clustered index page was updated or freed, resulting in the primary key fields for cached spatial index entries pointing to invalid addresses. (Bug #19999469)

  • InnoDB: An assertion was raised in the btr_cur_search_to_nth_level function. Both shared locks (s-locks) and shared-exclusive locks (sx-locks) should be permitted for all latch modes. (Bug #19984494)

  • InnoDB: An ALTER TABLE operation on a table with a FULLTEXT index raised an assertion. The table was already present in the cache and the FULLTEXT indexes were already initialized. When the table was reloaded, the FULLTEXT indexes were initialized again, causing the assertion. (Bug #19978288)

  • InnoDB: An UPDATE operation on a compressed temporary table raised an assertion. Shared temporary tablespace attributes were used when extending the tablespace for a compressed temporary table. (Bug #19976331)

  • InnoDB: Error messages regarding a size limitation on BLOB or TEXT data inserted in a single transaction were revised. (Bug #19975322)

  • InnoDB: Server logs reported a vector subscript out of range error. (Bug #19955501)

  • InnoDB: CHECK TABLE failed to check if the table is in a corrupt state before performing validation, resulting in an assertion. (Bug #19954054)

  • InnoDB: To avoid I/O on tablespaces that are rarely written to, the fsp_get_available_space_in_free_extents function now accesses metadata from cached fields instead of the tablespace header page in the buffer pool.

    This patch also includes the following optimizations:

    • To avoid lookups, fsp_fill_free_list() and some other functions now take a fil_space_t pointer instead of a numeric tablespace identifier.

    • The fil_extend_space_to_desired_size function was renamed to fil_space_extend and its API was simplified.

    • A new method, undo::Truncate::was_tablespace_truncated, was added to avoid a consistency check before flushing of truncated undo tablespace files.

    (Bug #19949683)

  • InnoDB: A failed DROP TABLE operation could leave a table in an inconsistent state without marking the table as corrupted. (Bug #19946781, Bug #74676)

  • InnoDB: A wrapper class was added to improve printing of quoted SQL identifiers, such as index, column and tablespace names. (Bug #19933607)

  • InnoDB: An ALTER TABLE operation raised an assertion. When a foreign key object was removed from the dictionary cache, an incorrect foreign key object was removed from the rb-tree. (Bug #19908343)

    References: This issue is a regression of: Bug #18806829.

  • InnoDB: DML operations on a table with full-text search indexes raised an invalid assertion. (Bug #19905246)

    References: This issue is a regression of: Bug #19314480.

  • InnoDB: A missing DBUG_RETURN() in ha_innobase::update_row raised an assertion. (Bug #19904800)

  • InnoDB: In debug builds, setting the innodb_limit_optimistic_insert_debug debug configuration option to 1 caused an infinite B-tree page split. (Bug #19904003, Bug #74605)

  • InnoDB: An ALTER TABLE ... DROP PRIMARY KEY, ADD PRIMARY KEY operation that changed the prefix length of the primary key field raised an assertion in the bulk insert code. (Bug #19896922)

  • InnoDB: Some InnoDB diagnostic output to stderr included unnecessary line breaks and lines without a preceding timestamp. Output from multiple threads could become interleaved due to messages being written out in several non-atomic steps. (Bug #19895222)

  • InnoDB: The innodb_create_intrinsic option, introduced in MySQL 5.7.5, was removed. (Bug #19893327)

  • InnoDB: As of MySQL 5.7.5, MySQL builds depend on atomic memory access primitives being present on the target platform. To simplify the code, HAVE_ATOMIC_BUILTINS was removed from the InnoDB source in MySQL 5.7.6. InnoDB now depends on Microsoft atomics on Windows, and on GCC-style atomics on other platforms. (Bug #19856411)

  • InnoDB: A severe error occurred during the log apply phase of an online ALTER TABLE operation that was converting a table with a UTF-8 charset to ROW_FORMAT=REDUNDANT. (Bug #19843246, Bug #19895661, Bug #20219871)

  • InnoDB: A multiple-table delete operation caused the server to halt. (Bug #19815702)

  • InnoDB: A buffer pool dump referred to a non-existing tablespace ID. (Bug #19814155)

    References: This issue is a regression of: Bug #19149177.

  • InnoDB: In debug builds, buf_block_align() could be called from debug assertion code while the buffer pool is being resized, resulting in a race condition. (Bug #19803497)

  • InnoDB: A FLUSH TABLES operation raised an assertion. (Bug #19803418)

  • InnoDB: The dict_boot() function did not set the maximum length of columns used for index fields, resulting in dict_index_node_ptr_max_size() returning incorrect values. (Bug #19791849)

  • InnoDB: When dummy tables are created, the autoinc_mutex member of the of the dict_table_t object was created unnecessarily. Similarly, the zip_pad.mutex object of dict_index_t object was created unnecessarily for dummy indexes. To avoid unnecessary mutex contention, autoinc_mutex and zip_pad.mutex objects are now allocated and initialized on the first lock attempt. (Bug #19788198, Bug #73361)

  • InnoDB: log_sys->mutex was not held when reading the fil_space_t::max_lsn field, causing a race condition. (Bug #19729855)

    References: This issue is a regression of: Bug #18645050.

  • InnoDB: btr_insert_into_right_sibling() could delete node pointers at the parent page. To avoid latch order violations and deadlocks with other threads, lock intention is now checked for leaf pages as well as upper non-leaf pages. (Bug #19729316)

  • InnoDB: InnoDB performed unnecessary table lookups in the change buffer during tablespace export operations. (Bug #19724300)

  • InnoDB: The fil_tablespace_deleted_or_being_deleted_in_mem() function, added in MySQL 4.1, was longer necessary and has been removed. There is a fallback check in fil_io() that returns DB_TABLESPACE_DELETED. (Bug #19719727)

  • InnoDB: To ease future development, the ha_innobase::create function was refactored. (Bug #19718568)

  • InnoDB: Redundant conditional branching and a redundant a check for srv_read_only_mode were removed from ha_innobase::create(). Redundant conditional branching and an unused local variable were removed from ha_innobase::delete_table(). (Bug #19712822)

  • InnoDB: Unused code related to UTF-8 handling for InnoDB FULLTEXT indexes was removed. (Bug #19712059)

  • InnoDB: The fil_index_tree_is_freed() function, which returned a false negative when the index root page was reallocated, was replaced by improved logic for freeing index trees. This patch also removed a redundant parameter that was passed to dict_drop_index_tree(). (Bug #19710798)

  • InnoDB: The InnoDB change buffer tree, which was created inside the InnoDB data dictionary cache unnecessarily, is now created directly, bypassing the cache. This patch also removes the DICT_UNIVERSAL flag, which was set in connection with DICT_IBUF. Neither of the flags is used for persistent data structures, which makes DICT_UNIVERSAL unnecessary. (Bug #19710650)

  • InnoDB: The fil_space_t::tablespace_version field, introduced to keep track of ALTER TABLE...DISCARD TABLESPACE followed by ALTER TABLE IMPORT TABLESPACE operations, was removed. The tablespace_version field ensured that a change buffer merge would not occur for old buffered entries while a tablespace with the same space_id was imported. The field was redundant and no longer required. (Bug #19710564)

  • InnoDB: Removed unused code related to index name lookup, and replaced a function that permitted duplicate index names. (Bug #19710348)

  • InnoDB: Column and index names were unnecessarily escaped in InnoDB diagnostic messages and interfaces. This patch also adds a new function, innobase_quote_identifier, for quoting FOREIGN KEY constraints and column names in SHOW CREATE TABLE output. (Bug #19704286)

  • InnoDB: When using the MySQL thread pool, connections encountered long semaphore waits during load testing. (Bug #19703758, Bug #19887285)

  • InnoDB: Since the introduction of fast index creation in MySQL 5.1, index objects have been added to the SYS_INDEXES internal data dictionary table before being committed. Uncommitted entries were identified by a prefix (defined as TEMP_INDEX_PREFIX). TEMP_INDEX_PREFIX was also used in the InnoDB data dictionary cache, resulting in complications when displaying or comparing index names. To address this problem, a new dict_index_t::uncommitted flag was introduced along with accessor methods is_committed() and set_committed(). Before this change, some InnoDB INFORMATION_SCHEMA tables displayed uncommitted index names with a preceding question mark. The question mark prefix is now omitted. (Bug #19702328)

  • InnoDB: InnoDB displayed tables names inconsistently in diagnostic messages. Some messages displayed table names using an internal representation while other messages displayed table names in a translated form. (Bug #19694618)

  • InnoDB: For FULLTEXT indexes, a lookup for the FTS_DOC_ID_INDEX was performed during DML operations. To avoid the costly lookups, a pointer to FTS_DOC_ID_INDEX is now cached at DDL time. (Bug #19693488)

  • InnoDB: To simplify code, the is_redo_skipped flag, introduced in MySQL 5.7.5 with the CREATE INDEX bulk load feature, was removed. The flag caused redo logging for page allocation to be skipped. Redo logs are now generated for page allocation, even when creating a new tablespace. (Bug #19693192)

  • InnoDB: An MLOG_FILE_NAME redo log record, which provides the information necessary to identify tablespace files that changed since the last checkpoint, were emitted on log checkpoint even though there were no changes to tablespace files. If a tablespace file is missing or unreadable on crash recovery, the inconsistency should be ignored if there are no redo logs to apply. For related information, see Tablespace Discovery During Crash Recovery. (Bug #19685095)

  • InnoDB: An unused parameter, archive_space_id, that was passed and ignored in the log_group_init function, was removed. (Bug #19669129)

    References: See also: Bug #16296837.

  • InnoDB: In read-only mode, a GIS data search using the MBRCONTAINS() function raised an assertion. (Bug #19664678)

  • InnoDB: Page reservation for the index tree was not performed before calling btr_page_alloc(). (Bug #19660261)

  • InnoDB: Building MySQL 5.7.5 on a Debian 7 32-bit system with GCC resulted in a MySQL server failure. The problem was due to a GCC bug (Debian Bug Report #764220) that causes incorrect code to be emitted when a function that takes a pointer or reference as a parameter is declared as attribute((const)) or attribute((pure)). The problem is known to occur on Debian Wheezy 7.6 x86 with g++-4.6 (Debian 4.6.3-14) 4.6.3 or g++ (Debian 4.7.2-5) 4.7.2, and on Debian Jessie/Sid amd64 with gcc (Debian 4.9.1-15) 4.9.1 or g++ (Debian 4.9.1-15) 4.9.1. The bug may exist in other gcc-4.x versions as well any GCC version that accepts the attribute((const)) or attribute((pure)) code.

    To avoid the bug, problematic attributes have been removed from MySQL functions that take pointers or references that they are dereferencing.

    This patch also removed instances of attribute((nonnull)), which do not always generate a warning when NULL is passed, and may not emit code for handling the NULL case. (Bug #19632776)

  • InnoDB: A rollback operation raised an assertion in lock_rec_free_all_from_discard_page_low() due to stale records locks on empty pages that were being removed from an index tree. (Bug #19628598)

  • InnoDB: The modify_clock value is now stored to allow the buf_page_optimistic_get() function, used to get optimistic access to a database page, to succeed in most cases. An unnecessary PAGE_HEAP_TOP (record heap top pointer) and FIL_PAGE_TYPE (file page type) set was removed from btr0bulk.cc. (Bug #19611367)

  • InnoDB: The dict_set_corrupted() function attempted to update the clustered index of the SYS_INDEXES data dictionary table incorrectly. (Bug #19584379)

  • InnoDB: Compiling with the new Clang 3.5 release resulted in a number of InnoDB compilation warnings. (Bug #19579603)

  • InnoDB: Removed unused API definitions from api0api.h and api0api.cc source files. (Bug #19579149)

  • InnoDB: The DICT_TF2_USE_FILE_PER_TABLE flag should be tested by the dict_table_use_file_per_table function to verify that the table uses a file-per-table tablespace. (Bug #19578222)

  • InnoDB: With innodb_create_intrinsic enabled, temporary tables created during ALTER TABLE operations were marked as optimized temporary tables, resulting in an assertion. Enabling innodb_create_intrinsic should only affect CREATE TABLE and CREATE INDEX operations. (Bug #19565749)

  • InnoDB: Valgrind testing returned a Conditional jump or move depends on uninitialised value(s) at buf_page_is_zeroes error. The unread portion of the page contained garbage values. (Bug #19536534)

  • InnoDB: An INSERT operation on a spatial index resulted in a crash in split_rtree_node(). The mbr_join_square function failed to check for infinity and NaN (not a number) values. (Bug #19533996, Bug #73776)

  • InnoDB: With change buffering enabled, a buffered sequence of operations that should not have been buffered resulted in an Unable to purge a record error. (Bug #19528825, Bug #73767)

  • InnoDB: Pages with a checksum value of zero were incorrectly treated as empty pages. A page should only be considered empty if its checksum value and LSN field values are zero. (Bug #19500258, Bug #73689)

    References: This issue is a regression of: Bug #17335427.

  • InnoDB: The C-style function, ib_logf(), used for writing log messages, has been removed in favor of C++ style classes (ib::info, ib::warn, ib::error, and ib::fatal). (Bug #19495721)

  • InnoDB: The InnoDB data dictionary was not updated when a ALTER TABLE ... CHANGE COLUMN operation changed the case of the column name. (Bug #19465984)

  • InnoDB: InnoDB returned a table not found error for a missing tablespace file. (Bug #19419026)

  • InnoDB: InnoDB shutdown stalled due to a user thread that was in a waiting state. (Bug #19386426)

  • InnoDB: After upgrading to MySQL 5.7, an ALTER TABLE operation on a tables created in MySQL 5.6 and containing GIS data would cause a serious error. (Bug #19368904)

  • InnoDB: After an online ALTER TABLE ... ADD INDEX operation, crash recovery failed due to a regression introduced with the CREATE INDEX bulk insert enhancement introduced in MySQL 5.7.5. (Bug #19316315, Bug #19308426)

  • InnoDB: On non-Windows platforms, os-file_pread and os_file_pwrite functions return -1 when an error occurs. This value was printed in an error message as the number of bytes read or written. Instead of printing the -1 value in the error message, a separate error message indicating a system call failure is now printed. Thanks to David Bennett for the patch. (Bug #19315210, Bug #73365)

  • InnoDB: A memory access violation caused fts_optimize_thread and mysqld to terminate. (Bug #19314480)

  • InnoDB: A procedure, called from a function to perform an operation on a temporary table, caused the server to halt. (Bug #19306524)

  • InnoDB: Attempting to shut down the server after starting the server with innodb_force_recovery=6 resulted in a hang. (Bug #19265668, Bug #73341)

  • InnoDB: The fil_inc_pending_ops() and fil_decr_pending_ops() functions have been replaced by fil_space_acquire() and fil_space_release(). This change removes a space ID lookup. The new functions are implemented in buf_load(), fsp_get_available_space_in_free_extents(), and lock_rec_block_validate(), which is a debug function. The patch for this bug also removed fil_tablespace_is_being_deleted(), which was an orphaned function. (Bug #19149177)

  • InnoDB: If the log sequence number (LSN) has not increased, the log_write_up_to() function should not initiate redo log writing. (Bug #19068569, Bug #73109)

  • InnoDB: A CREATE TABLE operation failed with a table is full error when running a MySQL server with innodb_flush_method=O_DIRECT on a Linux system with an ext3 file system. The error was due to an internal posix_fallocate() failure that occurs when O_DIRECT is specified. To allow the file operation to proceed, the internal posix_fallocate() failure now prints an error message to the error log. (Bug #18903979)

  • InnoDB: As part of a cleanup of InnoDB INSERT code paths, assertion code was added to ha_innobase::end_stmt() and other places at the start of DDL. Debug code was added to row_log_table_apply(). Assertion code was added to optimized temporary table-related functions, and unused parameters were removed. (Bug #18894337)

    References: This issue is a regression of: Bug #11758237.

  • InnoDB: A full-text search operation caused a segmentation fault. (Bug #18778259)

  • InnoDB: Enhancements introduced in MySQL 5.7.5 related to tablespace discovery during crash recovery caused a performance regression. (Bug #18645050)

  • InnoDB: If a database is named using uppercase letters on a MySQL server with lower_case_table_names=2 (which is default on OS X), InnoDB stores the database name as specified in the InnoDB internal system table (SYS_TABLES) but stores the name in lowercase on disk. During crash recovery, the case mismatch resulted in a conflict that marked the tablespace .ibd file as missing. The patch for this bug converts database names to lowercase on crash recovery. (Bug #18412598, Bug #72043)

  • InnoDB: A full-text query expansion search using a search phrase plus wildcard operator resulted in InnoDB: Did not find word ... for query expansion search errors. This patch also addressed an issue related to full-text indexes being “unsynced” by DDL rollback. (Bug #18229097, Bug #19831736)

    References: This issue is a regression of: Bug #17373659.

  • InnoDB: In debug builds, the InnoDB Lock Monitor asserted after a DROP TABLE operation, and the InnoDB Monitor encountered an assertion in buf_page_get_gen. (Bug #18062698, Bug #71343, Bug #18173184, Bug #68116)

  • InnoDB: A CREATE TABLE operation that failed when innodb_strict_mode was enabled succeeded without printing a warning when innodb_strict_mode was disabled. (Bug #17852083)

  • InnoDB: buf_LRU_free_page() would call buf_page_set_sticky(bpage), needlessly making removed pages sticky in some cases. (Bug #17407091, Bug #70228)

  • InnoDB: A slow shutdown (innodb_fast_shutdown=0) after crash recovery raised an assertion. Slow shutdown did not wait for background rollback operations to finish before proceeding. (Bug #16862810)

  • InnoDB: The criteria used to define a small tablespace was inconsistent. Thanks to Laurynas Biveinis for the patch. (Bug #16696906, Bug #68970)

  • InnoDB: For explicit cache coherency, a write barrier was added to the head of os_thread_create_func(), and a read barrier was added to assertion code in rw_lock_free_func(). (Bug #13364876, Bug #62692, Bug #18870970, Bug #72809)

  • InnoDB: A memcached append operation on an INT column caused a segmentation fault. append operations on INT columns are not supported and are now blocked. (Bug #75200, Bug #20209756)

  • InnoDB: The integer column value was handled incorrectly for the memcached incr and decr commands. (Bug #69415, Bug #20083106, Bug #74874, Bug #20044123)

  • Partitioning: When multiple columns are used in KEY partitioning, their order may help determine the partition in which the row is placed. Changing this order by means of an ALTER TABLE that uses ALGORITHM=INPLACE can lead to inconsistency when placing rows in partitions; in other words, a row inserted before such an operation is placed in one partition, but the same row inserted afterwards is placed in a different one. For this reason, altering the order of a multicolumn index online is no longer allowed when that index is also used as the base for partitioning the table by KEY; instead, you must use a copying ALTER TABLE to perform the change. (Bug #17896265)

  • Replication: The locking behavior of replication administration statements has changed to make SHOW SLAVE STATUS more concurrent. This makes the NONBLOCKING clause redundant for SHOW SLAVE STATUS and it has been removed, along with the Com_show_slave_status_nonblocking status variable. (Bug #20593028)

  • Replication: When enforce_gtid_consistency was set to WARN, if a second GTID consistency violating statement within a transaction was encountered, it was not raising a warning. This was due to the fact that by design the transaction context was marked as GTID violating, hence no other warnings were being issued until the transaction committed. The fix ensures that a warning is raised for all statements inside a transaction correctly. (Bug #20414559)

  • Replication: After restarting a slave, the first relay log was missing the Previous_gtids log event. Since MySQL version 5.7.6, a Previous_gtids log event is added to every log. This fix ensures that a Previous_gtids log event is correctly added to the first relay log. (Bug #20106390)

  • Replication: When purging binary logs and the first left binary log contained only a Previous_gtids log event, a lost_gtids->is_empty() assertion was caused. This was related to the fix for Bug#16741603 and has now been corrected. (Bug #20075721)

  • Replication: When using a slave configured to use a special character set such as UTF-16, UTF-32, or UCS-2, the receiver (I/O) thread failed to connect. The fix ensures that in such a situation, if a slave's character set is not supported then default to using the latin1 character set. (Bug #19855907)

  • Replication: If a client thread on a slave executed FLUSH TABLES WITH READ LOCK while the master executed a DML, executing SHOW SLAVE STATUS in the same client became blocked, causing a deadlock. The fix ensures that the read lock is only held during the period that the relay log is being updated and the deadlock is avoided. (Bug #19843808)

  • Replication: When using multi-source replication with multiple channels and with a multithreaded slave enabled, resetting the slave and then executing RESET SLAVE ALL, START SLAVE or STOP SLAVE resulted in a crash. This has now been fixed and the multithreaded slave can be restarted in a multi-source replication setup. (Bug #19784641)

  • Replication: The CHANGE REPLICATION FILTER statement can be used to create an empty filter, for example when clearing previously configured replication filters. This caused a crash in previous versions when creating an empty filter for REPLICATE_DO_TABLE, REPLICATE_IGNORE_TABLE, REPLICATE_WILD_DO_TABLE, or REPLICATE_WILD_IGNORE_TABLE. This fix ensures that these replication filters can be safely cleared by setting the filter to be empty. (Bug #19711674)

  • Replication: When using a MySQL version that had been compiled with the WITH_DEBUG option enabled, using expire_logs_days to purge binary logs caused a restart to crash the server. This problem arose after the fix for Bug #17283409. The fix ensures that current_thd is checked before calling DEBUG_SYNC(). (Bug #19553099)

  • Replication: When using a multithreaded slave, the slave receiver (SQL) thread stopped with an ER_MTS_CANT_PARALLEL error when issuing a LOAD DATA statement that tried to load data into a non-transactional table on the master but failed, for example due to a primary key violation. This was caused by the multithreaded slave applier incorrectly handling DELETE_FILE events. The fix ensures that a multithreaded slave handles DELETE_FILE events correctly. (Bug #19552923)

  • Replication: Sometimes the slave I/O thread leaves a partial group in the current relay log, for example when it is killed or stopped. After it is restarted, a new relay log is created on rotation and a pair of ROTATE_EVENT and FORMAT_DESCRIPTION_EVENT is replicated from master and written into the new relay log. When using a multithreaded slave, problems such as error 1755 were encountered when applying the remaining part of the group in the relay log. This fix ensures that if MASTER_AUTO_POSITION is enabled, then the worker rolls back the partial group, finishes its work, and then applies the new complete copy of the group. If MASTER_AUTO_POSITION is disabled, the worker does not roll back the partial group. (Bug #19545298)

  • Replication: Start log events were not checked by slaves for minimum size. (Bug #19145698)

  • Replication: When using row-based replication with slave_type_conversions enabled, a binary log with more than one Rows_log_event in succession caused a crash. This was due to the temporary tables generated as part of the slave_type_conversions process being released too early. This fix ensures that the temporary tables are not released too early, and also ensures that long transactions do not cause an out of memory error. (Bug #18770469, Bug #19704825)

  • Replication: When using binary log files that had been manually copied from the master, for example to avoid I/O thread reading delay, a multithreaded slave generated error 1755. Because the Previous_gtids log event is logged using the master's server_id and not the slave's server_id, the previous events were not being skipped correctly. This fix ensures that the events in Previous_gtids log event are always skipped, regardless of whether they are from the relay log (generated on the slave) or from the binary log (generated on the master and manually copied to the slave as the relay log). (Bug #17812024)

  • Replication: When replicating from an earlier version MySQL master, such as version 4.1, checksums are not used for events. Replicating to a slave running a newer version of MySQL, such as version 5.6, which has slave_sql_verify_checksum enabled by default meant that the last 4 bytes of events from the older master were being incorrectly interpreted as the checksum. A warning is now generated and to avoid such a situation, set slave_sql_verify_checksum=0 to disable checksums on the slave. (Bug #17276183)

  • Replication: When using multi-source replication and a multithreaded slave in a situation that required recovery of a channel, such as after a slave applier thread error, or after a crash, the channel was not being recovered correctly. This meant there was no attempt to fix gaps in transaction execution left by the stopped session, which led to some transactions being applied repeatedly. The fix ensures that in such a situation, the correct channel is passed through to multithreaded slave recovery. (Bug #74906, Bug #20046222)

  • Replication: Ignorable log events were introduced in MySQL 5.6, but were found to not be functioning correctly. This has now been fixed. (Bug #74683, Bug #19949915)

  • Replication: When an XA transaction was active, executing an internal rollback, for example using the BINLOG statement, resulted in an assertion. The fix ensures that a rollback happens only for a slave when a transaction spans multiple binary log files. Rollback does not happen now if the Format_description comes from the BINLOG statement being executed in the MySQL client. (Bug #74597, Bug #19928622)

  • Replication: The GTIDs of transactions committed in a group were not added to gtid_executed in order and this sometimes caused temporary gaps in gtid_executed. When these gaps occurred, the server would have to add and remove intervals from the GTID set, and this requires a mutex, which would cause contention and could reduce performance. The fix ensures that GTIDs are added to gtid_executed in the same commit order without gaps. (Bug #74328, Bug #19982543)

  • Replication: When gtid_mode=ON and log-bin=OFF, committed transaction GTIDs are added to the mysql.gtid_executed table. In such a configuration, the committed transaction GTID was not being correctly added to gtid_purged until the next time the server was restarted. The fix ensures that committed transaction's GTIDs are added to gtid_purged at the time of commit. (Bug #74279, Bug #19781336)

  • Replication: In a replication topology where:

    • the slave had GTID_MODE=ON and MASTER_AUTO_POSITION=1

    • the master had GTID_MODE=ON and had not executed any transactions since it was started

    if the slave used the MASTER_POS_WAIT function to wait until it had received the full binary log from the master while the master had not executed any transactions, then the MASTER_POS_WAIT function would never finish, or would time out. This was caused because after a server restart, the master's binary log ends with a Previous_gtids log event but this event was not being replicated, so the slave was not made aware of the master's binary log position. The fix ensures that the Previous_gtids log event is replicated correctly, so that the slave becomes aware of the correct binary log position on the master, ensuring that the MASTER_POS_WAIT function can finish. (Bug #73727, Bug #19507923)

  • Replication: When restarting MySQL with relay_log_recovery enabled to recover from a crash, if the SQL thread had never been started, the position from which to start recovery was not correctly initialized because Relay_Master_Log_File was missing. This fix ensures that in such a situation each of the relay logs, starting from the first relay log file, is searched for a rotate event from the master, which specifies where replication started from. This rotate event is then used to set the SQL thread's Relay_Master_Log_File and Relay_Log_Pos and recovery continues as normal. (Bug #73039, Bug #19021091)

  • Replication: When using GTIDs for replication and with MASTER_AUTO_POSITION enabled, if a slave requested GTIDs which had been already been purged by the master, the master was sending all available GTIDs. This happened because the master reads all available binary logs and searches for a binary log which contains a GTID that is not contained in the union of gtid_executed and gtid_retrieved. If such a GTID is found, the master starts sending the information starting from that location. In a situation where the union of the slave's gtid_executed and gtid_retreived set did not contain the master's gtid_purged set, the slave would expect GTIDs which had already been purged by the master. This fix ensures that in such a situation, the slave's I/O thread is aborted with an error "Master has purged binary logs containing GTIDs that the slave requires.". (Bug #73032, Bug #19012085)

  • Replication: When using a multithreaded slave with GTID based replication, enabling --replicate-same-server-id caused the slave thread to stop with an error and replication could not be started. This was caused by a Previous_gtids log event not being correctly filtered in such a setup and reaching the worker thread. The fix ensures that Previous_gtids log event is correctly processed by the coordinator thread. (Bug #72988, Bug #18967791)

  • Replication: A kernel mutex contention was being caused because mysqlbinlog was calling localtime() for every event read, which in turn called stat(/etc/localtime). This fix ensures that mysqlbinlog uses localtime_r(), which is optimized to store the read only timezone internal structure. This also means that mysqlbinlog now establishes the time zone at the beginning of processing and you can not change it during processing. This is the same behavior as MySQL server. (Bug #72701, Bug #18808072)

  • Replication: In normal usage, it is not possible for a slave to have more GTIDs than the master. But in certain situations, such as after a hardware failure or incorrectly cleared gtid_purged, the master's binary log could be truncated. This fix ensures that in such a situation, the master now detects that the slave has transactions with GTIDs which are not on the master. An error is now generated on the slave and the I/O thread is stopped with an error. The master's dump thread is also stopped. This prevents data inconsistencies during replication. (Bug #72635, Bug #18789758)

  • Replication: When using a GTID based replication slave with auto positioning enabled, there was a possibility that the last fully received transaction could be requested again by the slave I/O thread when the GTID of the transaction was not in the slave's gtid_executed set. This situation could occur for example if the SQL thread had not applied the transaction or a RESET MASTER statement was issued on the slave to clean up its gtid_executed set. The fix ensures that a GTID based replication slave using auto positioning does not ask for a fully received transaction twice, regardless of the slave's gtid_executed set, and it now only adds a GTID to the Retrieved_Gtid_Set when the whole transaction has been received. (Bug #72392, Bug #18629623, Bug #17943188)

  • Replication: When using SHOW SLAVE STATUS to monitor replication performance, Seconds_Behind_Master sometimes displayed unexpected lag behind the master. This was caused by Previous_gtids log events being written to the slave's relay log with a timestamp behind the master, and then being used to calculate the Seconds_Behind_Master. This fix ensures that events generated on the slave that are added to the relay log and are not used when calculating Seconds_Behind_Master. (Bug #72376, Bug #18622657)

  • Microsoft Windows: On Windows, the replace utility did not work. (Bug #16581605)

  • Solaris: Binary distributions for Solaris built with Sun Studio now ship with the stlport library due to a dependency of client programs on that library. (Bug #19845068)

  • Solaris: For 32-bit Solaris builds, alignment problems resulting from improper use of varargs function arguments caused core dumps and incorrect output. (Bug #74395, Bug #19821617)

  • For debug builds, an assertion could be raised during index selection if a spatial index used a column that was also part of the primary index. (Bug #20451454)

  • On Linux, trying to install a .dll plugin (intended for Windows) resulted in a memory leak. (Bug #20439894)

  • On 32-bit platforms, byte-count calculations for utf8 arguments for RPAD() could overflow and cause a server exit. (Bug #20316028)

  • mysqltest had a memory leak if another process shut down the server. (Bug #20221262)

  • The mysql_session_track_get_first() C API function returned 1 instead of 0 even after a valid query was executed to change the session state. (Bug #20126551)

  • On Ubuntu 14.10, MySQL install operations could fail to reload AppArmor. (Bug #20092641)

  • For debug builds, the server could raise an assertion during DELETE processing due to failure to handle a subquery that was required to be a scalar subquery but returned more than 1 row. (Bug #20086791)

  • mysql_list_fields() and mysql_stmt_prepare() could leak memory. This problem was introduced in MySQL 5.7.5 as a result of the change to EOF packet handling. (Bug #20065461, Bug #20065517)

  • Some queries with argumentless functions, GROUP BY, and WITH ROLLUP caused an assertion to be raised. (Bug #20034943)

  • A user with a name of event_scheduler could view the Event Scheduler process list without the PROCESS privilege. (Bug #20007583, Bug #20754369)

  • The mysql client could exit prematurely when invoked with the --xml option. (Bug #19974879)

  • InnoDB table checksum calculation could yield an incorrect result if the value of the innodb_checksum_algorithm system variable was modified during the operation. (Bug #19931177)

  • The LIKE operator could produce unreliable results of the ESCAPE clause contained an expression that was constant at execution time but unknown prior to that. (Bug #19931126)

  • Execution of certain BINLOG statements while temporary tables were open by HANDLER statements could cause a server exit. (Bug #19894987, Bug #20449914)

  • A malformed mysql.proc table row could result in a server exit for DROP DATABASE of the database associated with the proc row. (Bug #19875331)

  • SHOW GRANTS after connecting using a proxy user could display the password hash of the proxied user. (Bug #19817663)

  • For debug builds, the optimizer could produce a bad index scan cost when creating a temporary table for a derived table, and raise an assertion as a result. (Bug #19793998)

  • Unlocking a temporary table after locking and truncating it could cause a server exit. (Bug #19786309)

  • IN predicates could be incorrectly flagged as candidates for semijoin flattening, causing an assertion to be raised when flattening was attempted. (Bug #19779600, Bug #18932813)

  • Large values of the transaction_prealloc_size system variable could cause the server to allocate excessive amounts of memory. The maximum value has been adjusted down to 128K. A similar change was made for transaction_alloc_block_size. Transactions can still allocate more than 128K if necessary; this change reduces the amount that can be preallocated, as well as the maximum size of the incremental allocation blocks. (Bug #19770858, Bug #20730053)

  • RPM and DEB packages set the default sql_mode value incorrectly (they did not set ONLY_FULL_GROUP_BY, which is now included in the default value). (Bug #19766800)

  • Source RPM packages were missing the proper dependency on the Boost library. (Bug #19714453)

  • A server exit could occur for queries that compared two rows using the <=> operator and the rows belonged to different character sets. (Bug #19699237, Bug #20730155)

  • The Enterprise Encryption plugin could mishandle string arguments. (Bug #19688008, Bug #20730103)

  • The optimizer detected functional dependency for equality expressions of the form col_name = expr, but not for expressions of the form (col_name, ...) = (col_name, ...). Now it handles the latter as well. (Bug #19687724)

  • Certain InnoDB errors caused stored function and trigger condition handlers to be ignored. (Bug #19683834, Bug #20094067)

  • On some 32-bit platforms, GET_LOCK(lock_name, -1) returned immediately due to timeout rather than waiting for the lock. (Bug #19674349)

  • If a DML statement containing a subquery caused a deadlock inside InnoDB, InnoDB would roll back the transaction. This would not be noticed in the SQL layer, with the result that execution continued, eventually leading to an assertion being raised inside InnoDB. (Bug #19670163)

  • With default_authentication_plugin set to sha256_password, password hashes written to the binary log were in the wrong format. (Bug #19660998)

  • GROUP BY or ORDER BY on a CHAR(0) NOT NULL column could lead to a server exit. (Bug #19660891)

  • Under load, the server could exit while attempting to populate the OBJECT_TYPE column for selects from the events_waits_current Performance Schema table. (Bug #19658933)

  • ST_AsGeoJson() could fail when given an illegal max_dec_digits or options argument. (Bug #19657747)

  • Geohash spatial functions failed when given a geohash argument having a collation other than the default collation. (Bug #19657725)

  • Checks enforced by ONLY_FULL_GROUP_BY cannot reliably be run if a grouped query is part of CREATE VIEW. The MySQL server tried to run those checks and could exit; now only statements that actually use the view run the checks. (Bug #19636980)

  • For debug builds, an assertion could be incorrectly raised when a grouped query referred to a view. (Bug #19636409)

  • For debug builds: Adding a unique index to a POINT NOT NULL column triggered a warning and the key was not promoted to a primary key. Creating a unique index on a different non-NULL column in the same table then raised an assertion. (Bug #19635706, Bug #24469860)

  • When there is no change in session state, the OK packet sent from server to the client contained an unneeded byte at the end of the packet. (Bug #19625718)

  • Debug builds of mysql_install_db did not compile on Solaris 11 U2 due to use of the deprecated vfork() function. (Bug #19603400)

  • An assertion could be raised for either of these conditions: 1) A conversion to semijoin intended for scalar subqueries was applied to multiple-row subqueries. 2) An IN predicate for which the left-hand side was a scalar subquery converted to a semijoin was checked to see whether it could use materialization. (Bug #19586047)

  • For debug builds, if an intermediate or final result produced NaN or a negative number, ST_Distance() caused a server exit. This function now produces a ER_GIS_INVALID_DATA error instead. (Bug #19584716)

  • CMake configuration was adjusted to handle new warnings reported by Clang 3.5, using the -Wpointer-bool-conversion and -Wundefined-bool-conversion compiler options. (Bug #19584183)

  • If a CREATE TABLE or ALTER TABLE partitioning statement was executed in strict SQL mode and an ER_WRONG_TYPE_COLUMN_VALUE_ERROR error occurred, the sql_mode was reset to '' and the stack of error handlers was corrupted, leading to a server exit. (Bug #19584181)

  • Attempting to start the server on a port that was already in use produced Valgrind errors. (Bug #19566148)

  • Session state was not included with the results of queries saved in the query cache. (Bug #19550875)

  • Illegal CREATE TABLE statements could fail to create the table (as expected), but still generate table statistics in the Performance Schema. (Bug #19535945)

  • Setting session_track_system_variables to NULL could lead to an eventual server exit. (Bug #19514067)

  • The client protocol tracing plugin did not account for the removal of the EOF packet from the client/server protocol in MySQL 5.7.5. (Bug #19512199)

  • The default value for the condition filtering effect for equality conditions on nonindexed columns was adjusted from 0.005 to 0.1. The original value caused too-high estimates for the condition filtering effect for columns with low cardinality. (Bug #19505175)

  • A UNION statement for which the first query block returned a POINT column and the second returned a geometric column with a non-POINT value failed if the query used InnoDB temporary tables or stored the result in an InnoDB table. (Bug #19471564)

  • An assertion could be raised for queries evaluated using a semijoin LooseScan if an index scan was used on one index and a range scan on another index. (Bug #19465034)

  • In strict SQL mode, some SELECT statements could execute differently within and without stored procedures. (Bug #19418619)

  • If the audit_log plugin encountered a disk-full error, the server would exit.

    Now, if the file system to which the audit log is being written fills up, a “disk full” error is written to the error log. Audit logging continues until the audit log buffer is full. If free disk space has not been made available by the time the buffer fills, client sessions will hang, and stopping the server at the time of client sessions hanging will result in audit log corruption. To avoid this if client sessions are hung, ensure that free space is available on the audit logging file system before stopping the server. (Bug #19411485)

  • With the validate_password plugin activated and dictionary lookups enabled, passing a user-defined variable to PASSWORD() could cause a server exit. (Bug #19388163)

  • Statements that used Geohash spatial functions could not be prepared. (Bug #19383904)

  • The XPath number() function failed when invoked with no argument. Now MySQL treats number() as if it had been invoked for the current context node (in other words, as if number(.) had been used instead), which is the behavior called for in the XPath specification for this case. (Bug #19323016)

    References: This issue is a regression of: Bug #19056196.

  • With the query cache enabled, certain queries that began with comment sequences could cause invalid memory read errors. (Bug #19322795)

  • Certain GRANT PROXY statements affected only in-memory privileges and were reverted by FLUSH PRIVILEGES or a server restart. (Bug #19309652)

  • STR_TO_DATE() could mishandle conversion of numeric input to date, resulting in a server exit. (Bug #19047644)

  • Fixed a Valgrind warning for an out-of-bounds read while parsing '0E+'. (Bug #19047527)

  • Under certain conditions, DATE_FORMAT() could use the same buffer for its format argument and the function result, resulting in invalid memory reads. (Bug #19047488)

  • Conversion of a string to an IPv6 address could raise a Valgrind warning. (Bug #19047425)

  • For failure to create a temporary table due to being out of file descriptors, the server exited rather than returning an error. (Bug #18948649)

  • mysqldump failed to report a disk-full error if the dump destination was located on an NFS mount. (Bug #18817867)

  • Under certain conditions, a proxy user could expire the password of the proxied user. (Bug #18815349)

  • Previously, InnoDB permitted a foreign key to be created which referenced a parent table for which the user did not have sufficient privileges. Now, the user must have the REFERENCES privileges for the parent table to create a foreign key. (Bug #18790730, Bug #11746917)

  • The server could exit due to an optimizer failure to allocate enough memory for resolving outer references. (Bug #18782905, Bug #19892803)

  • The mysql_session_track_get_first() and mysql_session_track_get_next() C API functions could cause a client crash if passed invalid arguments. (Bug #18769620)

  • If two internal temporary tables were created based on the same aggregate function, the server could exit. (Bug #18766378)

  • For some queries that contained a derived table (subquery in the FROM clause), delay of materialization resulted in a suboptimal execution plan due to a less accurate row-count estimate. (Bug #18607971)

  • For some multiple-table UPDATE statements, the join order of the tables could incorrectly influence the result. (Bug #18449085)

  • ST_Touches() could cause a server exit for some inputs. (Bug #18304448)

  • Copying InnoDB tables containing full-text columns from Windows to Linux caused a server exit on Linux during full-text index initialization. (Bug #18285007, Bug #19864963, Bug #73155)

  • A server running with --default-authentication-plugin=sha256_password rejected connection attempts by MySQL 5.1 clients requiring a password. (Bug #18160400)

  • The validate_password plugin did not properly enforce password constraints for accounts authenticated by the sha256_password authentication plugin. (Bug #18140348)

  • For UPDATE and DELETE statements, the server could exit after attempting to access an uninitialized data structure. (Bug #18036143)

  • Execution of a prepared statement with a nested IN subquery and a view could cause a server exit. (Bug #17973601)

  • Starting the server with start service or mysqld_safe could result in failure to use the correct plugin directory. (Bug #17619241)

  • FLUSH TABLES on a FEDERATED table failed if the table had been idle longer than the wait_timeout time plus the TCP keepalive time. (Bug #17599258)

  • For FEDERATED tables, IGNORE handling for DELETE IGNORE statements was ignored. (Bug #17564775)

  • For debug builds, an assertion was raised for ALTER TABLE when accessing an indexed column for which the operation modified the column length, if the length was 767 and was being increased. (Bug #16886196)

  • Selecting all columns from INFORMATION_SCHEMA.TABLES did not reopen tables if they were in the table cache, but selecting a subset of those columns under the same conditions did reopen tables. (Bug #16869534)

  • Creating a FEDERATED table with an AUTO_INCREMENT column using a LIKE clause results in a server exit. (Bug #12671631)

  • For debug builds, a missing error check permitted certain ALTER TABLE statements that should fail to continue processing. (Bug #76515, Bug #20788817)

  • For RPM-based installation operations, no information was produced to indicate that mysql_install_db wrote the initial root password to $HOME/.mysql_secret. These operations now use mysqld --initialize, which writes the password to the standard error output. (Bug #75859, Bug #20518217)

  • For some full-text queries, incomplete optimizer cleanup regarding index use could affect subsequent queries against the same table. (Bug #75688, Bug #20442572, Bug #20261601)

  • For JSON-format EXPLAIN output, the filtered value was displayed to an unwarranted number of digits precsion. This value is now limited to two digits following the decimal point. (Bug #75663, Bug #20429156)

  • Pushed joins were not working for NDB tables. (Bug #75256, Bug #20234994)

  • For a slow network connection, the timeout for downloading Boost (600 seconds) could be too short. A new CMake option, DOWNLOAD_BOOST_TIMEOUT, is now available to configure the timeout. (Bug #75238, Bug #20223893)

  • For some queries with LIMIT, EXPLAIN could indicate that execution would be done using filesort, but execution actually was done using an index read. (Bug #75233, Bug #20219846)

  • Several spelling errors in error messages and the source code were corrected. Thanks to Otto Kekäläinen for the patch. (Bug #75084, Bug #20135835)

  • A bulk INSERT followed by other statements followed by LOAD DATA could produce incorrect AUTO_INCREMENT values. (Bug #75068, Bug #20126635)

  • When CMake did not find the required version of Boost, the error message did not indicate the required version. Now it does. (Bug #75026, Bug #20108908)

  • Enabling the log_timestamps system variable incorrectly required binary logging to be enabled. (Bug #75025, Bug #20108866)

  • During token processing, the parser check whether a token contained 7-bit data could be applied to the wrong token. (Bug #74984, Bug #20086997)

  • For a privilege error on a table underlying a view, a more general error should be supplied for attempts to access the view, so as not to provide information about the view contents. This did not happen in strict SQL mode. (Bug #74868, Bug #20032855)

  • For subqueries that used GET_LOCK() or RELEASE_LOCK() in decimal context, the server could create ill-defined temporary tables, resulting in a raised assertion. (Bug #74859, Bug #20031761)

  • default_password_lifetime was marked volatile, unnecessarily because it is protected with a mutex. Thanks to Stewart Smith for the patch. (Bug #74849, Bug #20029439)

  • Removed the unused grant_option global variable from mysqld.cc. Thanks to Stewart Smith for the patch. (Bug #74847, Bug #20029398)

  • InnoDB boolean full-text searches incorrectly handled + combined with parentheses; for example, +word1 +(>word2 <word3). (Bug #74845, Bug #20028323)

  • NULL as an expression was not recognized as a literal for calculation of Performance Schema statement digests. (Bug #74813, Bug #20015246)

  • MySQL failed to compile with GCC 4.9.1 in debug mode. (Bug #74710, Bug #19974500)

  • An optimizer cost model constructor allocated but did not destroy a cost constant object, resulting in a memory leak. (Bug #74590, Bug #19895764)

  • Certain queries could raise an assertion when a internal string operation produced a NULL pointer rather than an empty string. (Bug #74500, Bug #19875294, Bug #13358486, Bug #79988, Bug #22551116)

  • For mysql_install_db, the --no-defaults option was not passed to mysqld. (Bug #74477, Bug #19863782)

  • For debug builds, the server could exit due to an optimizer failure to allocate enough memory for group references. (Bug #74447, Bug #19855522)

  • For the table_io_waits_summary_by_table Performance Schema table, there was an off-by-one error for the COUNT_FETCH and COUNT_READ values. (Bug #74379, Bug #19814559)

  • Depending on contents, geometry collection objects were not properly destroyed, resulting in a memory leak. (Bug #74371, Bug #19813931)

  • Using (row subquery1) NOT IN (row subquery2) with NULL values in the left argument could cause an assertion failure. (Bug #74357, Bug #19805761)

  • Any index comment specified for ALTER TABLE ... ADD INDEX was ignored. (Bug #74263, Bug #19779365)

  • Reading a system variable with a NULL value inside a stored program caused any subsequent reads to return a NULL value even though the variable value might change across invocations of the stored program. (Bug #74244, Bug #19770958)

  • Storage engine API code and functions in the handler.h and handler.cc files that are never called or referenced were removed. (Bug #74207, Bug #19729286)

  • The -DENABLED_PROFILING=0 CMake option resulted in compilation errors. (Bug #74166, Bug #19730970)

  • With the change in MySQL 5.7.5 to InnoDB for the help tables in the mysql database, mysql_install_db became much slower for loading the help-table content. This was due to the INSERT statements loading with autocommit enabled. Now all the statements execute as a single transaction, not one transaction per statement. (Bug #74132, Bug #19703580)

  • On CentOS 6, specifying a relative path name for the --socket option caused MySQL startup script failure. (Bug #74111, Bug #19775856)

  • The group_concat_max_len system variable could be set to its maximum value at runtime, but not in an option file. (Bug #74037, Bug #19670915)

  • The server incorrectly wrote client-side error messages to the error log: Deadlock found when trying to get lock; try restarting transaction. (Bug #73988, Bug #19656296)

  • The client part of the sha256_password plugin could not be specified as a default client plugin (--default-auth=sha256_password) for users authenticating with other server plugins. (Bug #73981, Bug #19651687, Bug #17675203)

  • Miscalculation of memory requirements for qsort operations could result in stack overflow errors in situations with a large number of concurrent server connections. (Bug #73979, Bug #19678930, Bug #23224078)

  • REPEAT() wasted time concatenating empty strings. (Bug #73973, Bug #19646643)

  • The capabililty of using InnoDB for temporary tables in MySQL 5.7.5 resulted in certain queries failing: Some queries involving multiple-table UPDATE, queries involving long PRIMARY KEY values, and queries involving DISTINCT SUM(). (Bug #73927, Bug #19627741, Bug #73932, Bug #19628808, Bug #73702, Bug #19497209)

  • On Windows, setting the max_statement_time session variable greater than 0 resulted in a memory leak. (Bug #73897, Bug #19605472)

  • In Solaris 11.2, dtrace -V output changed from Sun D to Oracle D, causing detection of DTrace availability to fail during MySQL configuration. (Bug #73826, Bug #19586917)

  • DROP DATABASE failed if the database directory contained .cfg files (such as created by FLUSH TABLES FOR EXPORT). (Bug #73820, Bug #19573998)

  • On 32-bit systems, GLength() returned a non-INF value for LineString values of infinite length. (Bug #73811, Bug #19566186)

  • mysql_config --libs_r produces output containing link flags for libmysqlclient_r, even though that library was removed in MySQL 5.5 and replaced with a symbolic link to the underlying libmysqlclient library. The output now refers directly to libmysqlclient. (The implication is that it is no longer necessary to maintain the symbolic link for the sake of being able to use mysql_config --libs_r.) (Bug #73724, Bug #19506315)

  • For statement digest calculation, the Performance Schema failed to recognize signed literal numbers as values representable by ? and created multiple digests for statements that should have had the same signature. Now all instances of unary plus and unary minus followed by a number reduce to ? in digests. (Bug #73504, Bug #19389709)

  • Compilation on Windows using Visual Studio 2013 resulted in “unresolved external symbol” errors. (Bug #73461, Bug #19351573)

  • A server warning error message referred to the obsolete table_cache system variable rather than to table_open_cache. Thanks to Daniël van Eeden for the patch to fix some of the instances. (Bug #73373, Bug #19285052, Bug #75081, Bug #20135780)

  • Certain queries for which subquery materialization or UNION DISTINCT was used together with a hash index on a temporary table could produce incorrect results or cause a server exit. (Bug #73368, Bug #19297190)

  • If a table had a NOT NULL column, for an INSERT statement on the table for which the column value was not specified, the server produced ERROR 1048 "Column cannot be null" rather than Warning 1364 "Field doesn't have a default value" if there was a BEFORE trigger with an action type different from ON INSERT. (Bug #73207, Bug #19182009)

  • The IS_FREE_LOCK() and IS_USED_LOCK() function implementations contained a race condition due to which they could access freed memory when a user lock was concurrently checked and freed. Accessing freed memory could result in an incorrect function return value or server exit. (Bug #73123, Bug #19070633)

  • SHOW EVENTS in the performance_schema database returned an access-denied error, rather than an empty result as is done for INFORMATION_SCHEMA. Now an empty result is returned. (Bug #73082, Bug #19050141)

  • LOCK TABLES sometimes acquired an insufficiently strong lock for implicitly locked tables. (Bug #72887, Bug #18913551)

  • Sort order of output from a view could be incorrect when the view definition includes an ORDER BY clause but the view is selected from using a WHERE clause. (Bug #72734, Bug #18838002, Bug #81235, Bug #23207758)

  • The server no longer logs the following warnings because they are uninformative: Client failed to provide its character set. 'charset' will be used as client character set. (Bug #72543, Bug #18708334)

  • The ENABLED_LOCAL_INFILE CMake option was (incorrectly) enabled by default. (Bug #72106, Bug #18448743)

  • The server could fail to parse inserted strings for SET columns for which the column definition had exactly 64 elements. (Bug #71259, Bug #18020499)

  • Use of ODBC-format date literals could produce incorrect query results. (Bug #69233, Bug #16812821)

  • mysql_setpermission failed to properly quote user names in SQL statements that it generated. (Bug #66317, Bug #14486004)

  • For FEDERATED tables, DELETE FROM tbl_name statements were sent to the remote server as TRUNCATE TABLE tbl_name statements, with possible side effects on transaction handling and AUTO_INCREMENT processing. (Bug #42878, Bug #11751864)

  • A file created for an internal temporary table could cause problems if the file was orphaned for some reason and the file name was reused for later queries. (Bug #32917, Bug #11747548)

  • mysql_tzinfo_to_sql failed in STRICT_ALL_TABLES SQL mode if time zone tables contained malformed information. (Bug #20545, Bug #11745851)


PREV   HOME   UP   NEXT
Related Documentation
MySQL 5.7 Reference Manual
Download these Release Notes
PDF (US Ltr) - 3.2Mb
PDF (A4) - 3.2Mb