Changes in MySQL 5.7.5 (2014-09-25, Milestone 15)

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

• Compilation Notes

• Configuration Notes

• Deprecation and Removal Notes

• DTrace Support

• Error Handling

• InnoDB Notes

• Optimizer Notes

• Performance Schema Notes

• Security Notes

• Spatial Data Support

• SQL Mode Notes

• Functionality Added or Changed

• Bugs Fixed

Compilation Notes

• Important Change; Microsoft Windows: MySQL builds on Windows using Visual Studio now require Visual Studio 2013 or later. The previous requirement was Visual Studio 2010 or later. (Bug #18404381)

• Important Change: The atomic-operations API was simplified to use only the existing GCC built-in implementation or platform-provided implementations (for Windows, Solaris), and to remove the custom mutex-based fallback implementation. The retained implementations are those able to use CPU-native atomics. This simplifies the atomics APIs and related code and deals with bugs resulting from the fallback implementation.

  As part of this work, the (undocumented) WITH_ATOMIC_LOCKS and MY_ATOMIC_MODE_RWLOCKS CMake options were removed.

  On platforms where native atomics are supported, this change introduces no issues. For other platforms, here are potential MySQL compilation issues, and solutions:

  • 32-bit Linux variants that use GCC 4.1 will no longer work. This includes Red Hat 5, which is a supported platform. The solution to this problem is to use a new GCC or set the -march compiler option. For example, use GCC 4.4, which is available on Red Hat 5. For information about specifying compiler options, see Compiler Flags.

  • There may be issues on unsupported platforms. For example, 64-bit PowerPC, 32-bit ARM, and 64-bit ARM will not compile with older compilers. The solution for these cases is to use GCC 4.7 or later.

  (WL #7655)

• CMake now checks for minimum versions of supported compilers: gcc 4.4 (Linux, Solaris); Sun Studio 12u2 (Solaris client library); Clang 3.3 (OS X, FreeBSD). This check can be disabled with the -DFORCE_UNSUPPORTED_COMPILER=ON option. (Bug #19187034)

• Noisy compiler warnings on FreeBSD 10 were silenced. (Bug #18790490)

• CMake workarounds for older OS X and XCode versions were removed. On OS X, compilation always uses Clang, even for 32-bit builds.

  Compilation on OS X is now supported for OS X 10.8 and up, using XCode 5 and up. Compilation on older versions may work but is unsupported. (Bug #18510941)

• Previously, the MYSQL_MAINTAINER_MODE CMake option was turned on by default for debug builds and off for release builds, and MYSQL_MAINTAINER_MODE caused -Werror to be enabled when building with GCC. This made it cumbersome to enable -Werror under certain conditions, such as when compiling with Clang.

  Now, MYSQL_MAINTAINER_MODE is on by default when compiling debug builds with GCC, and MYSQL_MAINTAINER_MODE enbles -Werror regardless of whether GCC or Clang is used. Enabling -Werror with Clang can be done simply by explicitly setting -DMYSQL_MAINTAINER_MODE=1 when running CMake. In addition, some compilation warnings reported by Clang 3.4 were fixed, making it possible to build the default debug build with -Werror. (Bug #18313717)

• Build support was modified to produce the same warnings for Clang as for gcc. (Bug #17959689)

• 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

• Incompatible Change: mysql_install_db has been rewritten from Perl into C++. This enables it to be provided as an executable binary and eliminates its dependency on having Perl installed.

  The new implementation involves several other differences as well. The following items list some of the most significant changes. For more information, see mysql_install_db — Initialize MySQL Data Directory.

  • The executable binary version is located in the bin installation directory, whereas the Perl version was located in the scripts installation directory. For upgrades from an older version of MySQL, you may find a version of mysql_install_db in both directories. To avoid confusion, remove the version from the scripts directory. For fresh installations of MySQL 5.7.5 or later, mysql_install_db is only found in the bin directory, and the scripts directory is no longer present. Applications that expect to find mysql_install_db in the scripts directory should be updated to look in the bin directory instead.

  • Some options are handled differently. For example, the --datadir option is mandatory.

  • There are several new options. For example, there are options that afford explicit control over the administrative account that is created. By default, this is 'root'@'localhost', but you can use --admin-user and --admin-host to change the user and host parts of the account name.

  • Several options have been removed or replaced. For example, --skip-random-passwords has been replaced by --insecure.

  • mysql_install_db always overwrites the .mysql_secret file, rather than appending to it if it exists. It is assumed that immediately after installation, you will connect to the server using the file contents and reset the administrative password before proceeding to another deployment.

  • mysql_install_db no longer passes unrecognized options to mysqld. (But you can use --defaults-extra-file to specify an option file to be added to the mysqld bootstrapping command.)

  • mysql_install_db no longer creates a default my.cnf file.

  (WL #7688)

Deprecation and Removal Notes

• Incompatible Change: In MySQL 5.6.6, the YEAR(2) data type was deprecated. Support for YEAR(2) has now been removed. Once you upgrade to MySQL 5.7.5 or newer, any remaining YEAR(2) columns must be converted to YEAR(4) to become usable again. For conversion strategies, see 2-Digit YEAR(2) Limitations and Migrating to 4-Digit YEAR. For example, run mysql_upgrade after upgrading. (WL #6263)

• Incompatible Change: The InnoDB storage engine can no longer be disabled. The --skip-innodb option is deprecated and has no effect, and its use results in a warning. It will be removed in a future MySQL version. This also applies to its synonyms (--innodb=OFF, --disable-innodb, and so forth).

  A new innodb_lock_no_retry flag for the --debug option is now available. --debug='d,innodb_lock_no_retry' causes InnoDB to fail immediately during startup if locks cannot be acquired, rather than making 100 attempts before failing. This may be useful during testing or debugging to produce faster server exit when InnoDB cannot acquire its locks.

  One reason for disabling InnoDB is to enable starting a server instance using the same data directory as an existing instance. (MyISAM permits that, but InnoDB does not.) Because InnoDB can no longer be disabled, the workaround is to stop the existing instance before starting another so that there is only one active instance using a data directory at a time. (WL #7976)

• The deprecated timed_mutexes system variable has been removed. (Bug #18277305, WL #7436)

• The deprecated mysqlhotcopy utility has been removed from MySQL distributions. Alternatives include mysqldump and MySQL Enterprise Backup. (WL #7854)

• The deprecated mysqlbug, mysql_waitpid, and mysql_zap utilities have been removed from MySQL distributions. (WL #7689, WL #7826)

• The deprecated storage_engine system variable has been removed. Use default_storage_engine instead. (WL #7148)

DTrace Support

• MySQL now includes DTrace support on Oracle Linux 6 or higher with UEK kernel. If DTrace is present, server builds will detect it with no special CMake options required. For information about using DTrace on MySQL, see Tracing mysqld Using DTrace. (WL #7894)

Error Handling

• The server was made more consistent and resilient with regard to handling of statements for which the IGNORE keyword is specified.

  • The server failed to report warnings for INSERT IGNORE statements.

  • The server could fail to report warnings for multiple-table DELETE IGNORE statements.

  • UPDATE triggers for a table were invoked even for UPDATE IGNORE statements for which a unique index caused the update to be ignored.

  • For debug builds, an assertion could be raised for errors occurring in DELETE IGNORE statements.

  • For debug builds, an assertion could be raised for deadlocks resulting from DELETE IGNORE statements.

  • For DELETE IGNORE executed on the parent table in a foreign key relationship, foreign key violation errors were treated as warnings (correct), but rows that did not produce foreign key violations were not deleted.

  The server was made more consistent and resilient with regard to handling of statements in strict SQL mode.

  • In strict SQL mode, triggers could permit operations not permitted in strict mode.

  • In strict SQL mode, deprecation warnings about duplicate indexes were incorrectly promoted to errors.

  • Strict SQL mode was not applied to multiple-table DELETE statements.

  For more information about IGNORE and strict SQL mode, see Comparison of the IGNORE Keyword and Strict SQL Mode. (Bug #6196, Bug #11744960, Bug #43895, Bug #11752648, Bug #68726, Bug #16522924, Bug #16860715, Bug #16860829, Bug #14786621, Bug #17550423, Bug #42910, Bug #11751889, Bug #16976939, Bug #18526888, WL #6614, WL #6891)

InnoDB Notes

• Incompatible Change: A new log record type (MLOG_FILE_NAME) is used to identify file-per-table tablespaces that have been modified since the last checkpoint. This enhancement simplifies tablespace discovery during crash recovery and eliminates scans on the file system prior to redo log application. For more information about the benefits of this enhancement, see Tablespace Discovery During Crash Recovery.

  This enhancement changes the redo log format, requiring that MySQL be shut down cleanly before upgrading to or downgrading from MySQL 5.7.5. (WL #7142, WL #7806)

Optimizer Notes

• The optimizer computes more accurate costs for semijoin materialization. (Bug #18558561)

• Optimizer trace output for range access in the considered_access_path section has been improved: Instead of always printing "access_type": "ref" for index lookup types, "eq_ref", "ref", or "fulltext" is now printed. (Bug #18195373)

• During query execution plan construction, the optimizer now can use condition filtering to better use conditions on a table in estimating the number of qualifying rows to join to the next table. For example, even though there might be an index-based access method that can be used to select rows from the current table in a join, there might also be additional conditions for the table in the WHERE clause that can filter (further restrict) the estimate for qualifying rows passed to the next table.

  To control whether the optimizer considers additional filtering conditions, use the condition_fanout_filter flag of the optimizer_switch system variable. This flag is enabled by default but can be disabled to suppress condition filtering (for example, if a particular query is found to yield better performance without it).

  For more information, see Condition Filtering. (WL #6635)

• The optimizer now uses more exact index statistics. Currently, the improved values are used by InnoDB, with these effects:

  • In many cases, better execution plans result for queries for which previously a less optimal join index or table join order was chosen.

  • The row estimates in EXPLAIN output are more accurate, as well as the filter values in some cases.

  • Cardinality estimates in the index statistics displayed by SHOW INDEX are more accurate for InnoDB tables.

  (WL #7339)

• To generate execution plans, the optimizer uses a cost model that is based on estimates of the cost of various operations that occur during query execution. The optimizer has a set of compiled-in default “cost constants” available to it to make decisions regarding execution plans.

  The optimizer now also has a database of cost estimates to use during execution plan construction. These estimates are stored in the server_cost and engine_cost tables in the mysql system database and are configurable at any time: Any non-NULL cost estimate stored in the cost model tables overrides the corresponding compiled-in default estimate. Any NULL estimate indicates to the optimizer to use the compiled-in default.

  Implementation and testing is ongoing to make it safe for DBAs to change these values. Currently, changing them should be considered at your own risk.

  There is also a new FLUSH variant, FLUSH OPTIMIZER_COSTS, that causes the server to re-read the cost tables and apply any changed estimates to new sessions.

  For more information, see The Optimizer Cost Model.

  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 #6564, WL #6589, WL #7276, WL #7315, WL #7316)

Performance Schema Notes

• Incompatible Change: The Performance Schema now provides a user_variables_by_thread table that exposes user-defined variables. For more information, see Performance Schema User-Defined Variable Tables.

  In consequence of this change, the server now limits user-defined variable names to a maximum of 64 characters, the length of the VARIABLE_NAME column in the table. Previously, the server did not enforce a limit. The new limit is similar to the limit on the lengths of many other identifiers in MYSQL (see User-Defined Variables). Queries that use very long user-defined variable names must be rewritten to user shorter names.

  If you upgrade to this MySQL release from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate this change into the performance_schema database. (WL #6884)

• Previously, for the wait event tables (such as events_waits_current), the NUMBER_OF_BYTES column was NULL for table I/O waits; that is, for events for the wait/io/table/sql/handler instrument. For table I/O waits, this value now indicates the number of rows processed.

  In addition, for batch I/O operations (such as row fetches for table or index scans), the Performance Schema now can report a single event for N rows, rather than reporting a single-row event N times. This change significantly reduces Performance Schema overhead for table batch I/O by reducing the number of reporting calls. The tradeoff is lesser accuracy for event timing. Rather than time for an individual row operation as in per-row reporting, timing for batch I/O includes time spent for operations such as join buffering, aggregation, and returning rows to the client.

  For more information on the conditions under which batch I/O reporting occurs, see the description of the NUMBER_OF_BYTES column in The events_waits_current Table. (WL #7802)

• The Performance Schema stage event tables (events_stages_current, events_stages_history, and events_stages_history_long) contain two new columns that, taken together, provide a stage progress indicator for each row:

  • WORK_COMPLETED: The number of work units completed for the stage

  • WORK_ESTIMATED: The number of work units expected for the stage

  Each column is NULL if no progress information is provided for an instrument. Interpretation of the information, if it is available, is entirely up to the instrument implementation. Initially, to demonstrate the concept, the stage/sql/copy to tmp table instrument provides progress information if it is enabled. In this case, the unit for interpretation of the columns is number of rows copied.

  For more information, see Performance Schema Stage Event Tables.

  If you upgrade to this MySQL release from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate this change into the performance_schema database. (WL #7414)

Security Notes

• Incompatible Change: MySQL 5.6 deprecated passwords that used the older pre-4.1 password hashing format. Support for these passwords is now removed, which involves the following changes. Applications that use any feature no longer supported must be modified.

  • The server-side mysql_old_password authentication plugin is removed. Accounts that use this plugin are disabled at startup and the server writes an “unknown plugin” message to the error log. For instructions on upgrading accounts that use this plugin, see Migrating Away from Pre-4.1 Password Hashing and the mysql_old_password Plugin.

    The client-side mysql_old_password authentication plugin is removed from the C client library.

  • The --secure-auth option to the server and client programs is the default, but is now a no-op. It is deprecated and will be removed in a future MySQL version.

  • The --skip-secure-auth option to the server and client programs is no longer supported and using it produces an error.

  • The secure_auth system variable permits only a value of 1; a value of 0 is no longer permitted.

  • For the old_passwords system variable, a value of 1 (produce pre-4.1 hashes) is no longer permitted.

  • The OLD_PASSWORD() function has been removed.

  • The mysqladmin old-password command has been removed.

  (WL #8006)

• MySQL now includes a server-side authentication plugin named mysql_no_login for setting up accounts that accept no client connections. This plugin enables DBAs to implement the following use cases:

  • Stored program and view objects that perform sensitive or adminstrative operations must run with elevated privileges. Less-privileged users must be able to execute these objects but not be able to directly log in as the account that has the privileges. To implement this, create a no-login account using mysql_no_login, grant it the required privileges, define objects with a DEFINER of that account, and include SQL SECURITY DEFINER in the definitions.

  • Access to a proxy account must always be by the usual proxy mechanism, never by users logging in directly to the proxy account. To implement this, assign mysql_no_login as the authentication plugin when you create the proxy account.

  For more information, see No-Login Pluggable Authentication. (WL #7726)

• MySQL distributions now attempt to deploy with SSL and RSA capabilities enabled by default.

  To make it easier to support encrypted connections, MySQL servers compiled using OpenSSL now can automatically generate SSL and RSA files at startup if they are missing:

  • The server automatically generates server-side and client-side SSL certificate and key files in the data directory if the new auto_generate_certs system variable is enabled, no SSL options other than --ssl are specified, and the server-side SSL files are missing from the data directory. These files enable encrypted client connections using SSL.

  • The server automatically generates RSA private/public key-pair files in the data directory if the new sha256_password_auto_generate_rsa_keys system variable is enabled, no RSA options are specified, and the RSA files are missing from the data directory. These files enable secure password exchange using RSA over unencrypted connections for accounts authenticated by the sha256_password plugin.

  The server-side --ssl option value now is enabled by default for all servers. For servers compiled using OpenSSL, if --ssl is enabled and other SSL options are not given to configure SSL explicitly, the server attempts to enable SSL automatically at startup:

  • If the server finds valid SSL files named ca.pem, server-cert.pem, and server-key.pem in the data directory, it enables SSL to permit SSL connections by clients. (These files need not have been autogenerated; what matters is that they have the indicated names and are valid.)

  • If the server does not find valid SSL files in the data directory, it continues executing but does not enable SSL.

  For any SSL and RSA files that the server finds and uses automatically, it uses the file names to set the corresponding system variables (ssl_ca, ssl_cert, ssl_key, sha256_password_private_key_path, sha256_password_public_key_path).

  For more information, see Configuring MySQL to Use Encrypted Connections, and Creating SSL and RSA Certificates and Keys using MySQL. (WL #7699)

Spatial Data Support

• InnoDB: SPATIAL indexes can now be used for InnoDB tables. InnoDB supports indexing of spatial data types, including use of ALTER TABLE ... ALGORITHM=INPLACE for online operations (ADD SPATIAL INDEX). To support transaction isolation properties, InnoDB uses predicate locking. A predicate lock locks the minimum bounding rectangle (MBR) used for a query so that other transactions cannot insert or modify a row that would match the query condition.

  For more information, see Optimizing Spatial Analysis. and Predicate Locks for Spatial Indexes. (Bug #18674219, WL #6968, WL #6745, WL #6609)

• The Open Geospatial Consortium guidelines document the use of open polygons (polygons where the start point is not equal to the end point) but the MySQL GIS implementation did not support them. Now MySQL supports open polygons: An open polygon is converted to a closed one by appending the starting point to the point sequence. Before:

  mysql> SELECT AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))'));
  +---------------------------------------------------------------+
  | AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))')) |
  +---------------------------------------------------------------+
  | NULL                                                          |
  +---------------------------------------------------------------+

  After:

  mysql> SELECT AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))'));
  +---------------------------------------------------------------+
  | AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))')) |
  +---------------------------------------------------------------+
  | POLYGON((10 10,20 10,20 20,10 20,10 10))                      |
  +---------------------------------------------------------------+

  (Bug #17168699)

• GeometryCollection() returned NULL if the argument contained nonsupported geometries. Now GeometryCollection() returns all the proper geometries contained in the argument even if a nonsupported geometry is present. (Bug #17168643)

• This MySQL release makes increased use of the Boost.Geometry library to provide better reliability and increased functionality for spatial functions. As a result, several previously unimplemented functions have been implemented, and several previously existing functions now accept a wider range of geometry argument types (or argument type combinations for functions that take multiple geometries):

  • These previously unimplemented spatial operator functions are now available: ST_ConvexHull, ST_Difference(), ST_Intersection(), ST_SymDifference(), and ST_Union().

  • These previously existing functions are more robust and return non-NULL values for more geometry argument types: ST_Area(), ST_Centroid(), ST_Contains(), ST_Crosses(), ST_Disjoint(), ST_Distance(), ST_Envelope(), ST_Equals(), ST_Intersects(), ST_Overlaps(), ST_Touches(), and ST_Within(). These functions also exist as non-ST_ synomyms; for example, ST_Area() and Area() are synonyms.

  (WL #7220, WL #7221, WL #7236)

• MySQL now includes functions for converting between GeoJSON documents and spatial values: ST_AsGeoJSON() and ST_GeomFromGeoJSON(). For more information, see Spatial GeoJSON Functions. (WL #7444)

• MySQL now includes functions that enable manipulation of geohash values, which provides applications the capabilities of importing and exporting geohash data, and of indexing and searching geohash values:

  • ST_GeoHash() returns a geohash string given a return value length and either longitude and latitude values or a POINT value.

  • ST_LongFromGeoHash() and ST_LatFromGeoHash() return the longitude or latitude value, respectively, given a geohash string argument.

  • ST_PointFromGeoHash() produces a POINT value from a geohash string argument.

  (WL #7928)

SQL Mode Notes

• Incompatible Change: These SQL mode changes were made:

  • Strict SQL mode for transactional storage engines (STRICT_TRANS_TABLES) is now enabled by default.

  • Implementation of the ONLY_FULL_GROUP_BY SQL mode has been made more sophisticated, to no longer reject deterministic queries that previously were rejected.

    • MySQL now recognizes when a nonaggregated selected column is functionally dependent on (uniquely determined by) GROUP BY columns.

    • MySQL has an extension to standard SQL that permits references in the HAVING clause to aliased expressions in the select list. Previously, enabling ONLY_FULL_GROUP_BY disables this extension, thus requiring the HAVING clause to be written using unaliased expressions. This restriction has been lifted so that the HAVING clause can refer to aliases regardless of whether ONLY_FULL_GROUP_BY is enabled.

    In consequence, ONLY_FULL_GROUP_BY is now enabled by default, to prohibit nondeterministic queries containing expressions not guaranteed to be uniquely determined within a group.

  • The changes to the default SQL mode result in a default sql_mode system variable value with these modes enabled: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ENGINE_SUBSTITUTION.

  • The ONLY_FULL_GROUP_BY mode is now included in the modes comprised by the ANSI SQL mode.

  • A new function, ANY_VALUE(), is available that can be used to force MySQL to accept queries that it thinks should be rejected with ONLY_FULL_GROUP_BY enabled. The function return value and type are the same as the return value and type of its argument, but the function result is not checked for the ONLY_FULL_GROUP_BY SQL mode.

  If you find that having ONLY_FULL_GROUP_BY enabled causes queries for existing applications to be rejected, either of these actions should restore operation:

  • If it is possible to modify an offending query, do so, either so that nondeterministic nonaggregated columns are functionally dependent on GROUP BY columns, or by referring to nonaggregated columns using ANY_VALUE().

  • If it is not possible to modify an offending query (for example, if it is generated by a third-party application), set the sql_mode system variable at server startup to not enable ONLY_FULL_GROUP_BY.

  For more information about SQL modes and GROUP BY queries, see Server SQL Modes, and MySQL Handling of GROUP BY. (Bug #18486310, WL #2489, WL #7764)

Functionality Added or Changed

• Incompatible Change: The GET_LOCK() function has been reimplemented using the metadata locking (MDL) subsystem and its capabilities have been extended:

  • Previously, GET_LOCK() permitted acquisition of only one named lock at a time, and a second GET_LOCK() call released any existing lock. Now GET_LOCK() permits acquisition of more than one simultaneous named lock and does not release existing locks.

    Applications that rely on the behavior of GET_LOCK() releasing any previous lock must be modified for the new behavior.

  • The capability of acquiring multiple locks introduces the possibility of deadlock among clients. The MDL subsystem detects deadlock and returns an ER_USER_LOCK_DEADLOCK error when this occurs.

  • The MDL subsystem imposes a limit of 64 characters on lock names, so this limit now also applies to named locks. Previously, no length limit was enforced.

  • Locks acquired with GET_LOCK() now appear in the metadata_locks Performance Schema table. The OBJECT_TYPE column says USER LEVEL LOCK and the OBJECT_NAME column indicates the lock name.

  • A new function, RELEASE_ALL_LOCKS() permits release of all acquired named locks at once.

  For more information, see Locking Functions. (WL #1159)

• Incompatible Change: Previously, mysql_upgrade performed an upgrade by invoking the mysql and mysqlcheck clients. mysql_upgrade has been reimplemented to generate the required SQL statements itself and execute them by communicating directly with server.

  In consequence of this change, mysql_upgrade now supports the --bind-address option enabling the network interface for connecting to the server to be chosen. It also supports --net-buffer-length and --max-allowed-packet options enabling the initial and maximum communication packet size to be specified.

  Also in consequence of this change, mysql_upgrade no longer supports the --tmpdir option. This option specified the location of temporary files used to supply input to mysql, but it no longer has any purpose because mysql_upgrade no longer invokes mysql. Any upgrade scripts that invoke mysql_upgrade and use --tmpdir must be modified to remove that option. (WL #7308)

• InnoDB: For optimal shutdown and recovery performance, shutdown and recovery phases are now supported by the multithreaded page cleaner feature (innodb_page_cleaners) that was introduced in MySQL 5.7.4. (Bug #18805275)

• InnoDB: Work was done to introduce the notion of attachable transactions in InnoDB (for AutoCommit / ReadOnly / ReadCommitted / NonLocking transactions). This is used to read from InnoDB Data Dictionary tables. Along with this, attachable transactions were exposed to the server. Data Dictionary access code will use them to read Data Dictionary data. (WL #7828, WL #8003)

• InnoDB: You can now truncate undo logs that reside in undo tablespaces. This feature is enabled using the innodb_undo_log_truncate configuration option. For more information, see Truncating Undo Tablespaces. (WL #6965)

• InnoDB: InnoDB memory allocations now are instrumented for the Performance Schema and will appear in the memory summary tables. (WL #7777)

• InnoDB: Instead of inserting one index record at a time, InnoDB now performs a bulk load when creating or rebuilding indexes. This method of index creation is also known as a sorted index build. This enhancement, which improves the efficiency of index creation, also applies to full-text indexes. It is not supported with spatial indexes.

  A new global configuration option, innodb_fill_factor, defines the percentage of space on each page that is filled with data during a sorted index build, with the remaining space reserved for future index growth. For more information, see Sorted Index Builds. (WL #7277)

• InnoDB: The FIL_PAGE_FLUSH_LSN field, written to the first page of each InnoDB system tablespace file and to InnoDB undo tablespace files, is now only written to the first file of the InnoDB system tablespace (page number 0:0).

  As a result of this patch, if you have a multiple-file system tablespace and decide to downgrade from MySQL 5.7 to MySQL 5.6, you may encounter an invalid message on MySQL 5.6 startup stating that the log sequence numbers x and y in ibdata files do not match the log sequence number y in the ib_logfiles. If you encounter this message, restart MySQL 5.6 to ensure that startup has run properly. The invalid message should no longer appear. (WL #7990)

• InnoDB: The innodb_buffer_pool_size parameter is now dynamic, allowing you to resize the buffer pool without restarting the server. The resizing operation, which involves moving pages to a new location in memory, is performed chunks. Chunk size is configurable using the new innodb_buffer_pool_chunk_size configuration option. You can monitor resizing progress using the new Innodb_buffer_pool_resize_status status variable. For more information, see Configuring InnoDB Buffer Pool Size Online.

  See Configuring InnoDB Buffer Pool Size Online for more information. (WL #6117)

• Replication: When replicating from a master running a version earlier than MySQL 5.6.0 to a slave running MySQL 5.6.0 or later, the slave requires the master_uuid value, which is the server_uuid value from the master. The master_uuid value is unsupported on the older master, and in such a replication situation could become invalid on the newer slave. A check for empty master_uuid now ensures that the slave uses an empty value for master_uuid. (Bug #18338203)

• Replication: Retrying of transactions is now supported when multithreading is enabled on a slave. In previous versions, slave_transaction_retries was treated as equal to 0 when using multithreaded slaves. (Bug #16390504, Bug #68465, WL #6964)

• Replication: Global transaction identifiers (GTIDs) are now logged in a MySQL system table whenever they are enabled on the server, which lifts a previous requirement to use binary logging when replicating with GTIDs. If binary logging is disabled, the server stores the GTID for each transaction in the mysql.gtid_executed table as the transaction is executed. If binary logging is enabled, then, whenever the binary log is rotated or the server is shut down, the server also writes into the new binary log the GTIDs for all transactions from the previous binary log.

  Because the mysql.gtid_executed table can become filled with many rows with single-transaction GTIDs having the same originating server and sequential transaction IDs, the server compresses this table periodically whenever GTIDs are enabled. You can control the frequency with which the table is compressed by setting the executed_gtids_compression_period system variable. This variable's default value is 1000, which means that compression of the table is applied following each 1000 transactions. You can set the executed_gtids_compression_period to 0 to disable the compression altogether, but you should be aware that doing this may cause the space required by this table to increase significantly. (See mysql.gtid_executed Table Compression.)

  Compression of the mysql.gtid_executed table is performed by a dedicated thread. You can obtain information about the state of this thread in the threads Performance Schema table. (Bug #14730192, WL #6559)

• Replication: The system variable simplified_binlog_gtid_recovery can be used to change the way binary log files are searched for previous GTIDs during recovery, speeding up the process when a large number of binary log files exist. (Bug #69097, Bug #16741603, Bug #74071, Bug #19686914)

• Replication: The system variable binlogging_impossible_mode controls what happens if the server cannot write to the binary log, for example, due to a file error. For backward compatibility, the default for binlogging_impossible_mode is IGNORE_ERROR, meaning the server logs the error, halts logging, and continues updates to the database. Setting this variable to ABORT_SERVER makes the server halt logging and shut down if it cannot write to the binary log. (Bug #51014, Bug #11758766)

• Replication: To make monitoring of a replication setup easier, various replication related variables have been moved to the performance_schema tables. This is particularly helpful for monitoring multi-source replication. (WL #7817)

• Replication: The new SQL function WAIT_FOR_EXECUTED_GTID_SET() makes the current syncing option for the slave with master independent of the slave threads and improves the return value. (WL #7796)

• Replication: The new options binlog_group_commit_sync_delay and binlog_group_commit_sync_no_delay_count provide a way to configure the synchronization of the binary log. This enables more transactions to be synchronized together to disk at once, reducing the overall time to commit a group of transactions because the larger groups require fewer time units per group. (WL #7742)

• Replication: Multithreaded slaves can use the new slave_preserve_commit_order variable to ensure that the order which transactions were committed on the master is preserved on the slave. This prevents the slave from entering a state that the master was not in and is well suited to using multithreaded slaves for replication read scale-out. (WL #6813)

• New Debian7, Ubuntu12.04, and Ubuntu14.04 distribution support that was introduced with 5.6.17 now comes with the platform-specific packaging source placed under the packaging directory, in the deb-precise, deb-wheezy, and deb-trusty directories. (Bug #19020385)

• CMake support was updated to handle CMake version 3. (Bug #19001781)

• The rwlock used for the SAFE_HASH implementation is now instrumented for the Performance Schema. The instrument name is wait/synch/rwlock/mysys/SAFE_HASH::lock. (Bug #18991366)

• The (undocumented) binary-configure.sh script has been removed from MySQL distributions. (Bug #18694238)

• RHEL 4 is not supported for 5.7, so the support-files/RHEL4-SElinux file was removed. (Bug #18651087)

• The (undocumented) FEATURE_SET CMake option was removed. (Bug #18521389)

• Unused private fields reported by Clang's -Wunused-private-field compiler warning option were removed. (Bug #18489724)

• thr_alarm.h and thr_alarm.c were removed because they contain dead code almost exclusively. The remaining live code was moved to mysqld.cc. my_alarm.h and my_alarm.c were also removed, and the code from them that is actually used was moved to my_lock.c. (Bug #18411456)

• CMake support was updated to handle the new directory layout for Sun C++ 5.13. (Bug #73034, Bug #19010286)

• The obsolete and unmaintained charset2html utility has been removed from MySQL distributions. (Bug #71897, Bug #18352347)

• mysqld help text for --general_log was clarified. Thanks to Andrew Gaul for the patch. (Bug #71463, Bug #18127243)

• The fill_help_tables.sql file that is used to load server-side help table content now contains the following statement to suppress binary logging and prevent table contents from replicating to slaves:

  SET sql_log_bin=0;

  Because help table content is specific to the a particular server version, this prevents loading incorrect content into the slaves, which do not necessarily run the same version of MySQL as the master. (Bug #69564, Bug #17015822)

• The empty string provided for numeric or enumeration options (for example, --port="") produced inconsistent or confusing behavior. Such empty option values now are rejected with an error. (Bug #68055, Bug #16102788)

• The mysqladmin flush-logs command now permits optional log types to be given, to specify which logs to flush. Following the flush-logs command, you can provide a space-separated list of one or more of the following log types: binary, engine, error, general, relay, slow. These correspond to the log types that can be specified for the FLUSH LOGS SQL statement. Thanks to Daniël van Eeden for the patch. (Bug #60878, Bug #12368203)

• A new status variable, Max_used_connections_time, indicates the time at which Max_used_connections reached its current value. Thanks to Jordi Prats for the patch. (Bug #59738, Bug #11766596)

• Previously, on Unix and Unix-like systems, MySQL support for sending the server error log to syslog was implemented by having mysqld_safe capture server error output and pass it to syslog. The server now includes native syslog support, which has been extended to include Windows. Server error logging to syslog, Event Log, or a file, should be controlled using mysqld options. Doing so using mysqld_safe options is now deprecated. For more information about sending server error output to syslog, see The Error Log.

  In addition, system log output control is distinct from sending error output to a file or the console, on all platforms. Previously, this was true only for Windows. On Unix and Unix-like systems, error output now can be directed to a file or the console in addition to or instead of the system log as desired. This is true both for mysqld and mysqld_safe. Previously, mysqld_safe ignored its --syslog option with a warning if --log-error was also given. (Bug #55370, Bug #11762739, WL #7793, WL #8053)

• If connection IDs went beyond the 32-bit limit and started over at 1, the server now ensures that IDs still in use will not be reissued. (Bug #44167, Bug #11752851)

• Internally, spatial data types such as Geometry are represented as BLOB values, so when invoked with the --hex-blob option, mysqldump now displays spatial values in hex. (Bug #43544, Bug #11752369)

• Scalability for InnoDB tables was improved by avoiding THR_LOCK locks. As a result of this change, DML statements for InnoDB tables that previously waited for a THR_LOCK lock will wait for a metadata lock:

  • Explicitly or implicitly started transactions that update any table (transactional or nontransactional) will block and be blocked by LOCK TABLES ... READ for that table. This is similar to how LOCK TABLES ... WRITE works.

  • Tables that are implicitly locked by LOCK TABLES now will be locked using metadata locks rather than THR_LOCK locks (for InnoDB tables), and locked using metadata locks in addition to THR_LOCK locks (for all other storage engines). Implicit locks occur for underlying tables of a locked view, tables used by triggers for a locked table, or tables used by stored programs called from such views and triggers.

    Multiple-table updates now will block and be blocked by concurrent LOCK TABLES ... READ statements on any table in the update, even if the table is used only for reading.

  • HANDLER ... READ for any storage engine will block and be blocked by a concurrent LOCK TABLES ... WRITE, but now using a metadata lock rather than a THR_LOCK lock.

  The preceding changes are visible several ways. For example, when a DML statement such as INSERT INTO t1 in one session is blocked by LOCK TABLES t1 READ in another session:

  • In the Performance Schema, THR_LOCK acquisitions and waits will be registered in the metadata_locks table and for wait/lock/metadata/sql/mdl events rather than registered in the table_handles table and for wait/lock/table/sql/handler events.

  • In the process list (SHOW PROCESSLIST or INFORMATION_SCHEMA.PROCESSLIST), the state value will be Waiting for table metadata lock rather than Waiting for table level lock.

  • The Table_locks_immediate and Table_locks_waited status variables will no longer be incremented.

  Issues that went away as a result of these locking changes:

  • For debug builds, concurrent execution of LOCK TABLES ... READ and a DML statement affecting the same InnoDB table might lead to Found lock of type 6 that is write and read locked warnings in the error log.

  • Execution of DDL statements under LOCK TABLES might have led to deadlock if 1) this LOCK TABLES statement, in addition to the table to be changed by DDL, also had some tables read-locked or locked implicitly (for example, through triggers) and 2) there was some concurrent DML which was blocked on a table-level lock held by LOCK TABLES and 3) there was a concurrent PREPARE (or corresponding connector API call) which prepared a statement using tables to be affected by the first DDL and some other table which was affected by another DDL statement which had to wait for the DML statement.

  (Bug #42147, Bug #11751331, WL #6671)

• The mysql client now indicates whether USE statements produced warnings. (Bug #29965, Bug #11746951)

• In the MySQL client/server protocol, EOF and OK packets serve the same purpose, to mark the end of a query execution result. Due to recent changes in the OK packet (such as session state tracking), and to avoid repeating the changes in the EOF packet, the EOF packet is now deprecated. (WL #7766)

• The server-side help tables and time zone tables in the mysql system database now are InnoDB (transactional) tables. Previously, these were MyISAM (nontransactional) tables. The affected tables are:

  help_category
  help_keyword
  help_relation
  help_topic
  time_zone
  time_zone_leap_second
  time_zone_name
  time_zone_transition
  time_zone_transition_type

  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.

  START TRANSACTION and COMMIT statements have been added to the output from mysql_tzinfo_to_sql used to populate the time zone tables, to ensure that reload operations are permanent. (WL #7159)

• MySQL Server now supports an “offline mode” with these characteristics:

  • Connected client users who do not have the SUPER privilege are disconnected on the next request, with an appropriate error. Disconnection includes terminating running statements and releasing locks. Such clients also cannot initiate new connections, and receive an appropriate error.

  • Connected client users who have the SUPER privilege are not disconnected, and can initiate new connections to manage the server.

  • Replication slave threads are permitted to keep applying data to the server.

  Only users who have the SUPER privilege can control offline mode. To put a server in offline mode, change the value of the new offline_mode system variable from OFF to ON. To resume normal operations, change offline_mode from ON to OFF. In offline mode, clients that are refused access receive an ER_SERVER_OFFLINE_MODE error. (WL #3836)

• ALTER TABLE ... EXCHANGE PARTITION syntax now includes an optional {WITH|WITHOUT} VALIDATION clause. When WITHOUT VALIDATION is specified, ALTER TABLE ... EXCHANGE PARTITION does not perform row-by-row validation when exchanging a populated table with the partition, permitting database administrators to assume responsibility for ensuring that rows are within the boundaries of the partition definition. WITH VALIDATION is the default behaviour and need not be specified explicitly. For more information, see Exchanging Partitions and Subpartitions with Tables. (WL #5630)

• mysqlslap now has a --sql-mode option that enables the SQL mode to be set for the client session. (WL #7764)

• It is now possible to specify the storage engine the server uses for on-disk internal temporary tables (see Internal Temporary Table Use in MySQL), by setting the new internal_tmp_disk_storage_engine system variable. Permitted values are MYISAM (the default) and INNODB.

  In consequence of this change, the server is no longer prevented from using an in-memory temporary table for queries containing a string column in a GROUP BY or DISTINCT clause larger than 512 bytes for binary strings or 512 characters for nonbinary strings. (WL #6711)

• The custom rwlock implementation for Windows was replaced with standard Windows API calls. As a result of this change, Windows binaries require Windows 7 / Windows Server 2008 R2 or newer. In particular, Windows binaries no longer work on Windows Vista or Windows Server 2008 (plain, not R2). (WL #7914)

• The Boost.Geometry library now is required to build MySQL. Two new CMake options enable control over the library source location, and whether to download it automatically:

  • -DWITH_BOOST=path_name specifies the Boost library directory location. It is also possible to specify the Boost location by setting the BOOST_ROOT or WITH_BOOST environment variable.

  • -DDOWNLOAD_BOOST=bool specifies whether to download the Boost source if it is not present in the specified location. The default is OFF.

  For example, if you normally build MySQL placing the object output in the bld subdirectory of your MySQL source tree, you can build with Boost like this:

  mkdir bld
  cd bld
  cmake .. -DDOWNLOAD_BOOST=ON -DWITH_BOOST=$HOME/my_boost

  This causes Boost to be downloaded into the my_boost directory under your home directory. If the required Boost version is already there, no download is done. If the required Boost version changes, the newer version is downloaded.

  If Boost is already installed locally and your compiler finds the Boost header files on its own, it may not be necessary to specify the preceding CMake options. However, if the version of Boost required by MySQL changes and the locally installed version has not been upgraded, you may have build problems. Using the CMake options should give you a successful build.

Bugs Fixed

• Important Change; Partitioning: In an ALTER TABLE statement, the server accepted REBUILD with the name of a subpartition as valid syntax even though the REBUILD keyword in this case did nothing. Now REBUILD is rejected in such cases, and causes the statement to fail with an error. (Bug #19075411, Bug #73130)

  References: This issue is a regression of: Bug #14028340, Bug #65184.

• Important Change; Replication: A DROP TABLE statement may be divided into multiple statements before it is sent to the binary log if it contains regular (not temporary) tables and temporary tables, or if it contains temporary tables using both transactional and non-transactional storage engines. Now, when using GTIDs, DROP TABLE statements affecting these combinations of tables are no longer allowed unless the value of the gtid_next system variable is AUTOMATIC. This is because, with GTIDs enabled on the server, issuing a DROP TABLE in the cases just described while having only one GTID associated with each statement (the SQL thread does this following SET gtid_next='uuid:number') causes problems when there are not enough GTIDs for assignment to all the resulting statements following the division of the original DROP TABLE.

  A DROP TABLE statement might be split due to the behavior of the statement with respect to the current transaction varying, depending on table characteristics, as follows:

  • DROP TABLE of a regular (not temporary) table is committed immediately

  • DROP TABLE of a temporary table using a transactional storage engine is committed with the current transaction (following COMMIT)

  • DROP TABLE of a temporary table that uses a nontransactional storage engine is committed immediately

  Naming all three of these types of tables in a single DROP TABLE statement causes the MySQL server to divide the original statement into three separate DROP TABLE statements in the binary log. If GTIDs are enabled but the value of gtid_next is not AUTOMATIC, issuing a DROP TABLE statement that mixes any of the table types described previously causes the server to have an insufficient number of GTIDs to write with all of the resulting statements into the binary log. In addition, DROP TABLE IF EXISTS is always written in the binary log for all tables specified in the statement, even if some or all of the tables do not exist.

  Because temporary tables are handled differently by DROP TABLE depending on whether they use a transactional or nontransactional storage engine, any tables named by a DROP TEMPORARY TABLE statement that do not exist are assumed to be transactional. This means that, if a DROP TEMPORARY TABLE with two nontransactional temporary tables is issued on the master, it would writes only one DROP TABLE statement naming both tables. If one of the temporary tables no longer exists on the slave, then, when the SQL thread executes the statement, it tries to divide it into multiple statements due to it affecting a nontransactional (but existing) temporary table and a nonexistent transactional temporary table; this leads to problems because the SQL thread has only one GTID for the original DROP TABLE statement but must write two DROP TABLE statements in the binary log.

  In addition, when the slave dropped temporary tables after detecting that the master had restarted, it logged one DROP TABLE statement per pseudo-thread and per database, but combined temporary tables using transactional and nontransactional storage engines in a single DROP TABLE statement.

  Now, we throw an error in the client session if gtid_next is set to a uuid:number value and a DROP TABLE statement is issued mixing any of the table types described previously.

  In addition, we now group the nonexistent temporary tables and assume them to be transactional only if at least one transactional temporary table is dropped by the statement. If no transactional temporary tables are dropped, any nonexistent temporary tables are assumed to be nontransactional temporary tables.

  The slave now also handles dropping of temporary tables correctly in the event of the restart by the master. (Bug #17620053)

• Important Change; Replication: The maximum length that can be used for the password in a CHANGE MASTER TO statement is 32 characters. Previously, when a longer password was employed, it was accepted, but any excess length was silently truncated by the server. Following this fix, when the password's length exceeds 32 characters, CHANGE MASTER TO fails with an error. (Bug #11752299, Bug #43439)

• Performance; Replication: When processing the dump thread, a semisynchronous replication master checked whether or not the dump thread came from a semisynchronous slave by checking the value of rpl_semi_sync_slave_enabled, but did so for every operation performed on this thread, which had significant negative impact on performance. Now this check is made only once, when the dump thread is started, which should noticeably improve the performance of semisynchronous replication in most cases. (Bug #17932935)

• InnoDB; Partitioning: Large numbers of partitioned InnoDB tables could consume much more memory when used in MySQL 5.6 or 5.7 than the memory used by the same tables used in previous releases of the MySQL Server. (Bug #17780517, Bug #70641)

  References: This issue is a regression of: Bug #11764622, Bug #57480.

• InnoDB; Linux: The TTASFutexMutex, the mutex implementation that uses the Linux futex, failed to request m_lock_word alignment. (Bug #19525395, Bug #73760)

• InnoDB: If a crash occurs after a drop index action during a TRUNCATE TABLE operation, the root page could be left in a free state. On crash recovery, an LSN check failed to check free pages when attempting to pin the root page, resulting in an assertion. (Bug #19520482)

• InnoDB: Replaced a goto statement with an if statement in the fil_mutex_enter_and_prepare_for_io function in fil0fil.cc. (Bug #19488149)

• InnoDB: An INSERT operation on a table with spatial data columns raised an assertion. (Bug #19474851)

• InnoDB: Removed unused code related to binary log information stored in the InnoDB trx_sys page. (Bug #19471743)

• InnoDB: An ALTER TABLE ... ADD FOREIGN KEY operation could cause a serious error. (Bug #19471516, Bug #73650)

• InnoDB: Reduced mem_heap_zalloc calls in upd_create. Only a single call is necessary to allocate memory for upd_t. (Bug #19297656, Bug #73272)

• InnoDB: In debug builds, an INSERT operation affecting compressed tables would raise a sync-related assertion. (Bug #19295893)

• InnoDB: An ALTER TABLE operation raised an fk_tables.empty() assertion. After calling dict_load_foreigns(), all associated tables that are linked by a foreign key should be loaded to ensure that foreign keys are cached. (Bug #19267051)

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

• InnoDB: A transaction returned from the transaction pool was not in a clean state. (Bug #19244969)

• InnoDB: An MLOG_CHECKPOINT marker was incorrectly omitted when performing a log checkpoint. (Bug #19233510, Bug #73304)

• InnoDB: On crash recovery, InnoDB would call exit() when encountering a corruption or inconsistency. Some of the exit() calls have been removed to allow InnoDB to shut down properly. (Bug #19229231, Bug #73300)

• InnoDB: When multiple daemon_memcached_option options are defined, the INFORMATION_SCHEMA.GLOBAL_VARIABLES table and SHOW VARIABLES statement should only display the first daemon_memcached_option option that is defined in the command line string or in the MySQL configuration file. (Bug #19204759, Bug #73287)

• InnoDB: Running SHOW ENGINE INNODB STATUS repeatedly under performance testing conditions could result in a serious error. (Bug #19196052)

• InnoDB: Removed unused one_flush variable from storage/innobase/include/log0log.h. (Bug #19192364, Bug #73269)

• InnoDB: Retrieval of multiple values with a single get command would return incorrect results instead of an error message. The InnoDB memcached plugin does not currently support retrieval of multiple values with a single get command. (Bug #19172212, Bug #72453)

• InnoDB: Attempting to perform operations on a timed out key would cause the memcached daemon to crash and restart. (Bug #19172013, Bug #72586)

• InnoDB: An ALTER TABLE operation that does not perform a sort on the clustered index could result in a duplicate record. (Bug #19163915)

  References: See also: Bug #17657223.

• InnoDB: Improved error handling, diagnostics, and test coverage related to crash recovery error handling. (Bug #19145637, Bug #73179)

• InnoDB: Improved error handling for calls to handler::records(). (Bug #19142753, WL #6742)

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

• InnoDB: With a transaction isolation level less than or equal to READ COMMITTED, gap locks were not taken when scanning a unique secondary index to check for duplicates. As a result, duplicate check logic failed allowing duplicate key values in the unique secondary index. (Bug #19140907)

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

• InnoDB: A race condition that occurred when dynamically disabling innodb_adaptive_hash_index caused the purge thread to assert. (Bug #19069698, WL #6117, WL #6578)

• InnoDB: The INNODB_PAGE_ATOMIC_REF_COUNT CMake option is removed in MySQL 5.7.5. This option was enabled by default but could be disabled for systems that do not support atomic operations. As of MySQL 5.7.5, support for atomic operations is required to build MySQL, making the INNODB_PAGE_ATOMIC_REF_COUNT option obsolete. (Bug #19061440, WL #7655, WL #7682)

• InnoDB: In debug builds, an invalid rw_latch == RW_NO_LATCH assertion would cause the server to halt. (Bug #18977128)

• InnoDB: Added debug assertions to the adaptive hash index code to check that the tablespace ID in buffer blocks match the index space. (Bug #18965518, Bug #72986)

• InnoDB: During recovery, a segmentation fault would occur when marking a table as corrupt. (Bug #18942294)

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

• InnoDB: A code comment for the os_event_is_set function in storage/innobase/os/os0event.cc was incorrect. (Bug #18940008, Bug #72919)

• InnoDB: A latching order violation would occur while inserting BLOB data. (Bug #18883885)

• InnoDB: For PowerPC, InnoDB now uses special PowerPC instructions for setting priority of hardware threads in InnoDB mutex spin loops. Thanks to Stewart Smith for the contribution. (Bug #18842925, Bug #72754)

• InnoDB: The innodb_memcached_config.sql configuration script failed after running the mysql_secure_installation script, which removes the MySQL test database. The innodb_memcached_config.sql script now creates the test database if it does not exist. (Bug #18816381, Bug #72678)

• InnoDB: Removed unused function definitions and declarations from the InnoDB memcached API. (Bug #18815992, Bug #72723)

• InnoDB: CACHE_LINE_SIZE for PowerPC was changed from 64 bytes to 128 bytes. (Bug #18814859, Bug #72718)

• InnoDB: Opening a parent table that has thousands of child tables could result in a long semaphore wait condition. (Bug #18806829)

• InnoDB: trx_cleanup_at_db_startup failed to reset trx->rsegs->m-redo content in debug code. (Bug #18795594)

• InnoDB: On mysqld start, specifying multiple data files using the innodb_data_file_path option would return a Space id in fsp header error after data is written to the second file. (Bug #18767811)

• InnoDB: When storing BLOB data, InnoDB failed to reserve the required tablespace pages prior to allocating the pages, which raised an assertion on INSERT. (Bug #18756233)

• InnoDB: A failed in-place ALTER TABLE operation would leave behind nonunique temporary file names in the data dictionary preventing future ALTER TABLE operations on the same table due to temporary file name conflicts. To avoid this problem, temporary file names are made unique by appending a static global number that is initialized to a random distributed 32-bit number using ut_time() and ut_crc32(). The number is then incremented atomically for each assigned temporary file name. Previously, temporary files were named using the format #sql-ibtid, where tid is the table ID. Temporary files are now named using the format #sql-ibtid-inc, where tid is the table ID and inc is the incremented number. (Bug #18734396, Bug #72594)

• InnoDB: A regression introduced by the fix for Bug #11758237 resulted in a cursor->index->name == TEMP_INDEX_PREFIX assertion. (Bug #18723872)

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

• InnoDB: For single item full-text searches, deleted documents were included in inverse document frequency (IDF) calculations. (Bug #18711306, Bug #72548)

• InnoDB: The page_create function has been optimized to use simpler functions to initialize pages. (Bug #18704384)

• InnoDB: A DELETE operation on a table with full-text search indexes raised an assertion. (Bug #18683832)

  References: See also: Bug #14639605.

• InnoDB: To-be-imported tablespace files (FIL_TYPE_IMPORT) were not flushed after being converted to normal tablespace files (FIL_TYPE_TABLESPACE), resulting in too many open files. (Bug #18663997)

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

• InnoDB: When InnoDB is built as a shared library, attempting to load the InnoDB full-text search (FTS) INFORMATION_SCHEMA plugin would fail with a Can't open shared library 'ha_innodb.so' error. (Bug #18655281, Bug #70178)

• InnoDB: When calling the memcached flush_all command, InnoDB attempts to initialize a connection and a transaction. If the transaction is in TRX_STATE_NOT_STARTED state, InnoDB failed to set CONN_DATA->CRSR_TRX to NULL, resulting in a serious error. (Bug #18652854)

• InnoDB: An INSERT operation on a table with BLOB columns raised an assertion. (Bug #18646430)

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

• InnoDB: An INSERT operation on a table with GEOMETRY columns raised an assertion in rtr_page_split_and_insert(). (Bug #18644435)

• InnoDB: The temporary tablespace file (ibtmp1) was held open by the page_cleaner thread and could not be removed on startup, resulting in a hang. (Bug #18642372)

• InnoDB: A regression introduced in MySQL 5.6.5 would cause full-text search index tables to be created in the system tablespace (space 0) even though innodb_file_per_table was enabled. (Bug #18635485)

• InnoDB: After upgrading from 5.6.10 to MySQL versions up to and including MySQL 5.6.18, InnoDB would attempt to rename obsolete full-text search auxiliary tables on server startup, resulting in an assertion failure. (Bug #18634201, Bug #72079)

• InnoDB: In rare cases, the purge process would attempt to delete a secondary index record that was not marked for deletion, resulting in an inconsistent secondary index. (Bug #18631496)

• InnoDB: After running OPTIMIZE TABLE on an InnoDB table with a spatial index, running a SELECT statement that uses the spatial index could result in a crash. (Bug #18619945, Bug #72361)

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

• InnoDB: On startup, with innodb_file_per_table=ON, the page cleaner thread would raise a srv_get_active_thread_type() == SRV_NONE debug assertion when encountering an active master thread. (Bug #18598813)

• InnoDB: InnoDB would try to merge a b-tree change buffer for a dedicated undo tablespace. (Bug #18593561)

• InnoDB: Included unistd.h in innodb.cmake to enable futexes in debug builds. (Bug #18522549, Bug #72225)

• InnoDB: TRUNCATE TABLE would write page-level redo logs during the DROP TABLE step of a TRUNCATE TABLE operation. (Bug #18511398)

• InnoDB: A COMMIT operation related to full-text search resulted in a segmentation fault. (Bug #18503734)

• InnoDB: srv_active_wake_master_thread() was called directly in innobase_commit and innobase_prepare, waking up the master thread and incrementing srv_activity_count. srv_active_wake_master_thread() should only be called after committing write transactions, not after read-only transactions or rollbacks. This patch also replaces some calls to srv_active_wake_master_thread() with calls to ib_wake_master_thread(). (Bug #18477009, Bug #72137)

• InnoDB: A DB_LOCK_WAIT during a foreign key check caused redundant delete marking, resulting in a failing assertion. (Bug #18451287)

• InnoDB: With UNIV_SYNC_DEBUG enabled, a late call to sync_check_enable() would result in an m_enabled assertion failure. (Bug #18433658)

• InnoDB: InnoDB would write to the redo log for an IMPORT TABLESPACE operation before the tablespace import was complete. (Bug #18424134)

• InnoDB: The InnoDB memcached plugin would call plugin_del without acquiring the lock_plugin mutex. This bug fix also addresses a race condition in ib_cursor_delete_row. (Bug #18409840)

• InnoDB: The os_event_wait_time_low function would sometimes return OS_SYNC_TIME_EXCEEDED before the sync time has elapsed. (Bug #18386498)

• InnoDB: With persistent statistics enabled, SHOW TABLE STATUS output and the TABLE_ROWS column of INFORMATION_SCHEMA.TABLES could report an incorrect number of table rows for tables with externally stored pages. (Bug #18384390)

• InnoDB: Running a SELECT on a partitioned table caused a memory access violation in memcpy(). (Bug #18383840)

  References: See also: Bug #18167648.

• InnoDB: A regression introduced by the fix for Bug#18069105 could result in a table corruption and failing assertions. (Bug #18368345)

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

• InnoDB: The data file was not opened prior to calling fil_fusionio_enable_atomic_write(), resulting in an assertion failure. (Bug #18368241)

• InnoDB: The fix for Bug#17699331 caused a high rate of read/write lock creation and destruction which resulted in a performance regression. (Bug #18345645, Bug #71708)

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

• InnoDB: Code quality improvements for the redo log subsystem. (Bug #18345004)

• InnoDB: Added the C++ ostream mechanism for error logging. (Bug #18320915)

• InnoDB: Removed the recv_max_parsed_page_no code variable, which was only used in a diagnostic error message. (Bug #18312967)

• InnoDB: buf_pool->flush_rbt, which is only intended to be used for recovery, would be allocated for database creation and never freed. (Bug #18253089)

• InnoDB: Calls to sched_getcpu would cause page faults. (Bug #18225489)

• InnoDB: ib_heap_resize failed to verify that new_size is greater than or equal to old_size before calling memcpy. (Bug #18178915)

• InnoDB: After crash recovery and with UNIV_DEBUG enabled, purge failed with a buf_pool_from_bpage(bpage) == buf_pool assertion failure. (Bug #18154145)

• InnoDB: Assertion code in buf_page_release_latch() in buf0buf.ic was too restrictive. (Bug #17869571)

• InnoDB: For each insert, memset would be called three times to allocate memory for system fields. To reduce CPU usage, the three memset calls are now combined into a single call. (Bug #17858679, Bug #71014)

• InnoDB: The fix for Bug#16418661 added superfluous buf_flush_list() logic to InnoDB startup code. (Bug #17798076, Bug #70899)

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

• InnoDB: A problem renaming temporary tables during an ALTER TABLE operation would raise an assertion and print a warning to the error log. Temporary table names were not sufficiently unique. (Bug #17713871)

• InnoDB: In-place ALTER TABLE operations requiring a table rebuild would sort the clustered index even though the primary key order remained unchanged. This behavior caused unnecessary temporary table usage and I/O. (Bug #17657223)

• InnoDB: Under certain circumstances, adaptive hash index latches (btr_search_latch) were persistent. With atomics-based rw-locks (read-write locks), persistent adaptive hash index latches are unnecessary and may block other adaptive hash index updates. (Bug #17554489, Bug #70216)

• InnoDB: A race condition in fts_get_next_doc_id resulted in Duplicate FTS_DOC_ID and Cannot find index FTS_DOC_ID_INDEX in InnoDB index translation table errors. (Bug #17447086, Bug #70311)

  References: See also: Bug #16469399.

• InnoDB: Enabling the InnoDB Table Monitor would result in a ib_table->stat_initialized assertion failure. (Bug #17039528, Bug #69641)

• InnoDB: Redo log writes for large, externally stored BLOB fields could overwrite the most recent checkpoint. The 5.6.20 patch limits the size of redo log BLOB writes to 10% of the redo log file size. The 5.7.5 patch addresses the bug without imposing a limitation. For MySQL 5.5, the bug remains a known limitation. (Bug #16963396, Bug #19030353, Bug #69477)

• InnoDB: The error log message that is printed on CREATE TABLE when the number of BLOB or TEXT fields exceed the row size limit did not provide sufficient information. The error message now provides the maximum row size, current row size, and the field that causes the maximum row size to be exceeded. (Bug #16874873, Bug #69336)

• InnoDB: An in-place ALTER TABLE operation on a table with a broken foreign key constraint could raise an assertion. (Bug #16869435)

• InnoDB: The lock_number_of_rows_locked function used a bit vector to track the number of record locks held by a transaction. To optimize reporting, the bit vector was replaced by a simple counter. (Bug #16479309, Bug #68647)

• InnoDB: Inserting a record into an InnoDB table with a key that falls between the maximum key of a full page and the minimum key of the “next” page could result in unnecessary page splits and under-filled pages. If the insert point is at the end of a page, InnoDB now attempts to insert to the next page before splitting the page. (Bug #15923864, Bug #67718)

• InnoDB: With innodb_max_dirty_pages_pct=0 buffer pool flushing would not be initiated until the percentage of dirty pages reached at least 1%, which would leave up to 1% of dirty pages unflushed. (Bug #13029450, Bug #62534)

• InnoDB: Due to differences in memory ordering on different processor types, some mutex and read-write lock flags were not read consistently. (Bug #11755438, Bug #47213)

• InnoDB: Debug assertion code in file row0ins.cc did not account for rw-lock shared-exclusive (sx-lock) mode, resulting in an assertion failure. (Bug #73534, Bug #19420253)

• InnoDB: With foreign_key_checks=0, InnoDB permitted an index required by a foreign key constraint to be dropped, placing the table into an inconsistent and causing the foreign key check that occurs at table load to fail. InnoDB now prevents dropping an index required by a foreign key constraint, even with foreign_key_checks=0. The foreign key constraint must be removed before dropping the foreign key index. (Bug #70260, Bug #17449901)

• Partitioning: When the index_merge_intersection flag (enabled by default) or the index_merge_union flag was enabled by the setting of the optimizer_switch system variable, queries returned incorrect results when executed against partitoned tables that used the MyISAM storage engine, as well as partitioned InnoDB tables that lacked a primary key. (Bug #18167648)

  References: See also: Bug #16862316, Bug #17588348, Bug #17648468.

• Partitioning: Selecting from a table having multiple columns in its primary key and partitioned by LIST COLUMNS(R), where R was the last (rightmost) column listed in the primary key definition, returned an incorrect result. (Bug #17909699, Bug #71095)

• Replication: Misleading or confusing error messages have been revised, which were produced in the following 2 cases when using mysqlbinlog with the --raw option:

  • When this option was used together with --include-gtids.

  • When this option was used together with --exclude-gtids and --read-from-remote-master=BINLOG-DUMP-NON-GTIDS.

  (Bug #19459836, Bug #73625)

• Replication: After the fix for Bug #16861624, killing a multithreaded slave worker which was waiting for a commit lock caused a debug assertion to fail. This fix ensures that such a situation can not occur. (Bug #19311260)

• Replication: Temporary errors related to a slave worker thread which was retrying a transaction were visible in SHOW SLAVE STATUS. This fix ensures that slave worker threads do not store temporary errors in the slave status. (Bug #19282301)

• Replication: A corrupted header length in FORMAT_DESCRIPTION_LOG_EVENT could cause the server to stop unexpectedly. This was due to FORMAT_DESCRIPTION_LOG_EVENT being considered invalid if the header length was too short. (Bug #19145712)

• Replication: Removed an unnecessary write lock that was taken by an internal function while adding a GTID to a GTID set, which should improve the performance of the function and the code dependent on it during such operations. (Bug #18963555, Bug #72977)

• Replication: Semisynchronous replication did not work as expected when the rpl_semi_sync_master_wait_no_slave and rpl_semi_sync_master_wait_for_slave_count variables were set. The values of the variables were changed, but the related internal status was not updated during initialization. (Bug #18835117, Bug #18466390)

• Replication: RESET SLAVE ALL did not clear IGNORE_SERVER_IDS, although this statement should clear any values that are set by CHANGE MASTER TO. Now RESET SLAVE ALL always empties the list of server IDs to ignore, whenever it is executed. (Bug #18816897)

• Replication: The same internal function had effects which caused three similar problems when resetting or starting slaves. These three issues are listed here:

  • RESET SLAVE automatically set the heartbeat period (Slave_heartbeat_period) to its default value.

  • RESET SLAVE automatically set SSL_VERIFY_SERVER_CERT to the default.

  • When a server was not configured as a slave (that is, when no CHANGE MASTER TO statement had yet been executed), the subsequent failure of START SLAVE was expected but had the unintended side effect of resetting the heartbeat period to the default.

  The function has been rewritten such that code affecting heartbeat or SSL certificate usage has been eliminated or moved to a more appropriate location, eleminating the side effects formerly seen with RESET SLAVE or a failed START SLAVE.

  As part of this fix, in order to be able to keep heartbeats enabled by default when changing the master, if host and port are given but the heartbeat period is not specified in a CHANGE MASTER TO statement, we force it to the default value. (Bug #18791604, Bug #18778485, Bug #18777899)

• Replication: mysqlbinlog --raw did not check for errors caused by failed writes, which could result in silent corruption of binary logs. Now in such cases it stops with an error. (Bug #18742916, Bug #72597)

• Replication: When committing a transaction, a flag is now used to check whether a thread has been created, rather than checking the thread itself, which uses more resources, particularly when running the server with master_info_repository=TABLE. (Bug #18684222)

  References: See also: Bug #17967378.

• Replication: When a slave worker thread tried to execute a statement that was too large, the resulting error caused a crash. Now in such cases, the error is truncated to fit the size of the buffer. (Bug #18563480)

• Replication: Log rotation events could cause group_relay_log_pos to be moved forward incorrectly within a group. This meant that, when the transaction was retried, or if the SQL thread was stopped in the middle of a transaction following one or more log rotations (such that the transaction or group spanned multiple relay log files), part or all of the group was silently skipped.

  This issue has been addressed by correcting a problem in the logic used to avoid touching the coordinates of the SQL thread when updating the log position as part of a relay log rotation whereby it was possible to update the SQL thread's coordinates when not using a multithreaded slave, even in the middle of a group. (Bug #18482854)

• Replication: When using GTIDs with MASTER_AUTO_POSITION enabled, if an I/O thread was restarted it failed with an ER_GTID_NEXT_TYPE_UNDEFINED_GROUP error due to a partial transaction not being correctly rolled back before resuming the I/O thread. This fix ensures that the partial transaction is correctly rolled back. (Bug #18472603)

• Replication: When using row-based replication, updating or deleting a row on the master that did not exist on the slave led to failure of the slave when it tried to process the change. This problem occurred with InnoDB tables lacking a primary key. (Bug #18432495, Bug #72085)

• Replication: A multithreaded slave now checks that a free worker is available to dispatch the next event. In previous versions, a multithreaded slave crashes with a worker error if the thread coordinator can not find a free worker. The crash was caused when the coordinator did not return a free worker, for example if the coordinator was aborted at the same time using STOP SLAVE. (Bug #18363515)

• Replication: When replicating from a MySQL 5.5 or earlier master to a MySQL 5.6 or later slave, the SOURCE_UUID column of the slave's performance_schema.replication_connection_status table contained random data. Now in such cases, SOURCE_UUID is left blank. (Bug #18338203)

• Replication: During relay log initialization, the thread context was used as a flag for the reconstruction of the retrieved GTID set, an operation that does not depend on this parameter. This could be problematic if relay log initialization was called in another context other than the legacy replication scenario; if the invocation was made in a context where the thread context was always present, this prevented the set's reconstruction. The opposite could also happen when the thread context was not present, which cause the initialization to be performed twice.

  To avoid such issues, the thread context flag is replaced with a new flag that allows the reconstruction in all contexts but prevents multiple invocations. (Bug #18337036)

• Replication: When mysqlbinlog processed multiple binary log files into a single output file, this file was not in a useful state for point-in-time recovery, when it failed with the error, When @@SESSION.GTID_NEXT is set to a GTID, you must explicitly set it to a different value after a COMMIT or ROLLBACK. Please check GTID_NEXT variable manual page for detailed explanation. Current @@SESSION.GTID_NEXT is 'xyz'. When mysqlbinlog processes a binary log containing GTIDs, it outputs SET gtid_next statements, but gtid_next is set to undefined whenever a commit occurs; this left gtid_next undefined when the server had finished processing the output from mysqlbinlog. When the next binary log file started with one or more anonymous statements or transactions, the combination of gtid_next being left undefined at the end of the first binary log and the second binary log containing anonymous transactions to the error described previously (Error 1837, ER_GTID_NEXT_TYPE_UNDEFINED_GROUP).

  To fix this issue, now, whenever mysqlbinlog encounters this situation, it inserts SET gtid_next = AUTOMATIC if required to avoid leaving the previous binary log with gtid_next undefined.

  In addition, as a result of this fix, mysqlbinlog no longer outputs session variable information for every binary log; now, this value is printed only once unless it changes. (Bug #18258933, Bug #71695)

• Replication: Quotation marks were not always handled correctly by LOAD DATA when written into the binary log. (Bug #18207212, Bug #71603)

• Replication: Changing master_info_repository between TABLE and FILE could produce duplicate values in the Replicate_Ignore_Server_Ids column of the output from SHOW SLAVE STATUS and the Ignored_server_ids column of the mysql.slave_master_info table. This could arise because the list of IDs stored internally by the server was not always sorted before checking for duplicates when inserting new values into the list. Now the list of server IDs to be ignored is always sorted, prior to performing this check. (Bug #18192817, Bug #18593479, Bug #18920203)

• Replication: In certain cases, the server mishandled triggers and stored procedures that tried to modify other tables when called by CREATE TABLE ... SELECT. This is now handled correctly as an error. (Bug #18137535)

• Replication: The REPLICATE_WILD_DO_TABLE and REPLICATE_WILD_IGNORE_TABLE options for CHANGE REPLICATION FILTER could be employed with values which contained no period (.) character, even though values for these options must be in the format db_name.tbl_name.. (Bug #18095449)

• Replication: When used on a table employing a transactional storage engine, a failed TRUNCATE TABLE was still written to the binary log and thus replayed on the slave. This could lead to inconsistency when the master retained data that was removed on the slave.

  Now in such cases TRUNCATE TABLE is logged only when it executes successfully. (Bug #17942050, Bug #71070)

• Replication: Beginning in MySQL 5.6.20, when a user specified AUTO_INCREMENT value falls outside of the range between the current AUTO_INCREMENT value and the sum of the current and number of rows affected values it is replicated correctly. In previous versions, an error was generated by the slave even if the user specified AUTO_INCREMENT value fell outside of the range. (Bug #17588419, Bug #70583)

• Replication: When the I/O thread reconnected to a master using GTIDs and multithreaded slaves while in the middle of a transaction, it failed to abort the transaction, leaving a partial transaction in the relay log, and then retrieving the same transaction again. This occurred when performing a rotation of the relay log. Now when reconnecting, the server checks before rotating the log in such cases, and waits first for any ongoing transaction to complete. (Bug #17326020)

• Replication: On Windows, mysqldump failed if the error log file was deleted (missing) from the active MySQL server. (Bug #17076131)

• Replication: When the binary log was rotated due to receipt of a SIGHUP signal, the new binary log did not contain the Previous_gtid_event required for subsequent processing of that binary log's GTID events. Now when SIGHUP is received, steps are taken to insure that the server writes the necessary Previous_gtid_event to the new log before writing any GTID events to the new log. (Bug #17026898)

• Replication: The CLIENT_REMEMBER_OPTIONS flag for compressed slave connections is no longer reset and all options are retained. This restores functionality of all options to compressed slave connections. (Bug #72901, Bug #18923691, Bug #73324, Bug #19244772)

• Replication: When using row-based replication, setting a slave's slave_rows_search_algorithms variable to HASH_SCAN caused an ER_KEY_NOT_FOUND error even though that record existed in the storage layer. This fix ensures that the unique key for each record is correctly maintained and such a situation does not occur. (Bug #72788, Bug #18860225)

• Replication: When using row-based replication, running a long transaction involving a large number of events could trigger an Out of Memory (OOM) error if the slave's table structure was not compatible with the master's table structure. Such an incompatible situation could occur if the table on the slave had been manually changed, or when replicating between different MySQL versions that have different data types. This OOM error was caused because the virtual temporary tables created for the row conversion were not being freed until the end of the transaction, which was a problem when replicating large numbers of events.

  Starting with this version, such virtual tables are correctly freed during the conversion process. (Bug #72610, Bug #18770469)

  References: See also: Bug #19692387.

• Replication: The error messages generated when a duplicate server UUID causes issues during replication have been improved. The slave error now identifies the duplicate server UUID and the master error identifies the zombie thread that has been killed. (Bug #72578, Bug #18731211)

• Replication: When an event group was spanned across multiple relay log files, a slave could incorrectly identify GTID-header group boundaries. This meant that when a transaction was retried, or if the SQL thread was stopped in the middle of a transaction after some rotates, the Gtid_log_event was being silently skipped on the slave, and the transaction was logged with the slave's GTID. This problem also impacted on using START SLAVE UNTIL MASTER_LOG_POS = log_pos; with GTIDs enabled. If log_pos was in the middle of a transaction, the Gtid_log_event was not correctly detected as the beginning of the transaction and replication stopped before this event. With this fix, threads correctly detect that they are part of a group, and this is used to check if a Gtid_log_event is part of a transaction. (Bug #72313, Bug #18652178, Bug #18306199)

• Replication: When gtid_mode=ON, and a transaction is filtered out on the slave, the GTID of the transaction is still logged on the slave as an “empty” transaction (consisting of a GTID followed immediately by BEGIN and then COMMIT). This is necessary to prevent the transaction from being retransmitted the next time the slave reconnects or is involved in a failover. The current fix addresses two issues relating to such “empty” transactions:

  • No empty transaction was generated for CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE statements.

  • If the slave used a database filter (--replicate-do-db or --replicate-ignore-db option), no empty transaction was generated.

  (Bug #71376, Bug #18095502, Bug #18145032)

• Replication: Client applications should be able to set the BINLOG_DUMP_NON_BLOCK flag in the initial handshake packet (COM_BINLOG_DUMP). Clients connecting to a server issuing a COM_BINLOG_DUMP with the flag unset do not get an EOF when the server has sent the last event in the binary log, which causes the connection to block. This flag, which was removed in error in MySQL 5.6.5, is now restored in the current release.

  As part of this fix, a new --connection-server-id option is added to mysqlbinlog. This option can be used by the client to test a MySQL server for the presence of this issue. (Bug #71178, Bug #18000079)

• Replication: On a master that is using semisynchronous replication, where rpl_semi_sync_master_wait_no_slave is enabled and rpl_semi_sync_master_timeout is set to long timeout, killing the I/O thread could cause the server to hang on shutdown. This fix ensures that if the dump thread finds that there no semisynchronous slaves connected to the master, the setting of rpl_semi_sync_master_wait_no_slave is ignored and the shutdown proceeds correctly. (Bug #71047, Bug #17879675)

• Replication: Uninstalling and reinstalling semisynchronous replication plugins while semisynchronous replication was active caused replication failures. The plugins now check whether they can be uninstalled and produce an error if semisynchronous replication is active. To uninstall the master-side plugin, there must be no semisynchronous slaves. To uninstall the slave-side plugin, there must be no semisynchronous I/O threads running. (Bug #70391, Bug #17638477)

• Replication: When using semisynchronous replication, if the binary log position was changed to a future position on a slave then an assertion error was generated on the master. This fix ensures that in such a situation the future position is correctly acknowledged and an error is instead generated on the slave. (Bug #70327, Bug #17453826)

• Replication: Replication of tables that contained temporal type fields (such as TIMESTAMP, DATETIME, and TIME) from different MySQL versions failed due to incompatible TIMESTAMP types. The fractional TIMESTAMP format added in MySQL 5.6.4 was not being correctly converted. You can now replicate a TIMESTAMP in either format correctly according to the slave_type_conversions variable. (Bug #70124, Bug #17532932)

• Replication: A group of threads involved in acquiring locks could deadlock when the following events occurred:

  1. Dump thread reconnects from slave; on master, a new dump thread tries to kill zombie dump threads; having acquired the thread's LOCK_thd_data, it is about to acquire LOCK_log.

  2. Application thread executing show binary logs, having acquired LOCK_log and about to acquire LOCK_index.

  3. Application thread executing PURGE BINARY LOGS; having acquired LOCK_index, it is about to acquire LOCK_thread_count.

  4. Application thread executing SHOW PROCESSLIST (or SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST), having acquired LOCK_thread_count and about to acquire the zombie dump thread's LOCK_thd_data.

  This leads to the 4 threads deadlocking in the same order which the threads have been listed here.

  This problem arises because there are ordering rules for LOCK_log and LOCK_index, as well as rules for ordering LOCK_thread_count and LOCK_thd_data, but there are no rules for ordering across these two sets of locks. This was because the internal mysqld_list_processes() function invoked by SHOW PROCESSLIST acquired LOCK_thread_count for the complete lifetime of the function as well as acquiring and releasing each thread's LOCK_thd_data. Now this function takes a copy of the threads from the global thread list and performs its traversal on these, and only after releasing LOCK_thread_count. During this traversal, removal from the global thread list is blocked using LOCK_thd_remove such that the copies that would otherwise be destroyed by the removal remain valid during traversal. The locking order following this fix is shown here:

  LOCK_thd_remove -> LOCK_thd_data -> LOCK_log -> LOCK_index -> LOCK_thread_count

  (Bug #69954, Bug #17283409)

  References: See also: Bug #73475, Bug #19364731, Bug #19365180.

• Replication: When an SQL thread which was waiting for a commit lock was killed and restarted it caused a transaction to be skipped on slave. This fix ensures that thread positions are correctly persisted and transactions resume at the correct position. (Bug #69873, Bug #17450876)

• Microsoft Windows: To help with crash analysis on Windows, more information has been added to the core file that is written on mysqld abort when the core-file option is enabled. (Bug #14041454)

• With DTrace support enabled, certain other compilation options could cause the build to fail. (Bug #19506247)

• yaSSL client code did not validate the encryption size or session ID length, which could cause the client to exit. (Bug #19463277, Bug #19463565)

• Before fsync operations, the server reports a wait, but it reported a table-lock wait rather than a sync wait. This is a minor problem, possibly resulting in come incorrect thread pool plugin statistics. (Bug #19428231)

• The optimizer could raise an assertion due to incorrectly handling the table map while sorting an internal temporary table. (Bug #19416826)

• yaSSL could fail preauthorization if the client supplied inaccurate buffer lengths. (Bug #19370676, Bug #19355577)

• Using Multi-Range Read (MRR) for table access could leak Performance Schema instrumented table handles. (Bug #19301539)

• For InnoDB full-text searches, invalid multibyte gb10830 characters could cause a server exit. (Bug #19233075)

• Competition between threads could lead to timeout failure trying to rotate the audit log file. (Bug #19184973)

• On Windows, sql_yacc.cc and sql_yacc.h were generated twice during the build process. This can lead to compilation failure if parallel processes are permitted. (Bug #19060850, Bug #27470071, Bug #89482)

• Repetitive functions called as arguments to ExtractValue() were not always handled correctly. (Bug #19051306)

• For large sets, EXPORT_SET() could produce undefined results or a cause a server exit. (Bug #19048609)

• Invalid utf16 data could cause the server to become unresponsive. (Bug #18937504)

• LPAD() and RPAD() could cause a server exit if the pad string argument was not well formed. (Bug #18935421)

• The optimizer could create a zero-length column for a temporary table, causing a server exit. (Bug #18928848)

• In debug builds, certain range queries could cause an assertion failure. (Bug #18921626)

• Improper copying of query strings between the Prepared_statement and THD data structures could result in a server exit. (Bug #18920075)

• Performance Schema memory instrumentation did not honor the ENABLED flag in the setup_instruments table or the consumers in the setup_consumers table. This has been corrected, with the result that unnecessary statistics are not collected and overhead is reduced. (Bug #18900309)

• When a SELECT included a derived table in a join in its FROM list and the SELECT list included COUNT(DISTINCT), the COUNT() returned 1 even if the underlying result set was empty. (Bug #18853696)

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

• Conversion failure of “zero” dates in strict SQL mode could cause a server exit. (Bug #18840123)

• Modulo operations on DECIMAL values in some cases could overflow and cause a server exit. (Bug #18839617)

• Enabling optimizer trace could cause a server exit for queries with a subquery in a HAVING clause. (Bug #18791851)

• SHA and MD5 functions failed for operations using the internal filename character set and could cause a server exit. (Bug #18786138)

• Large arguments passed to mysqldump could lead to buffer overflow and program exit. (Bug #18779944)

• If a materialized subquery read from a view, and contained an inner subquery having an outer reference to a column of the view, results could be incorrect. (Bug #18770217)

• Passing bad arguments to SHA2() could cause a server exit. (Bug #18767104)

• Spatial operations on InnoDB tables could fail attempting to access nonexistent index statistics. (Bug #18743725)

• ORDER BY of a GIS function that was given invalid arguments could cause a server exit. (Bug #18701868)

• The code for processing the gb18030 character set had a too-strict assertion for single-character invalid characters. (Bug #18700668)

• After a metadata change, a reprepared trigger could cause a server exit or prune an incorrect partition. (Bug #18684393)

• mysql_secure_installation ignored options defined after an unrecognized option. (Bug #18659533)

• VALIDATE_PASSWORD_STRENGTH() could enter an infinite loop for some arguments. (Bug #18636291)

• ALTER TABLE on a partitioned table could result in the wrong storage engine being written into the table's .frm file and displayed in SHOW CREATE TABLE. (Bug #18618561)

• The server could fail to properly reprepare triggers that referred to another table after that table was truncated. (Bug #18596756, Bug #72446, Bug #18665853)

• Compiler flags were not passed to DTrace, causing problems for 32-bit builds cross-compiled on 64-bit platforms. (Bug #18593044)

• For conditions on the form t.key NOT IN (c1, c2, ...), if one or more of the c1, c2 was NULL, the optimizer generated incorrect range predicates, possibly yielding incorrect results.

  The range optimizer would build predicates for empty in-lists (because NULL values are removed from NOT IN (in-list)). (Bug #18556403, Bug #18715670)

• After conversion of an in-memory internal temporary table to disk, the server could use a pointer to the old table, resulting in a server exit. (Bug #18535226)

• For queries executed using Loose Index Scan, incorrect cost estimates could be produced if index statistics were unavailable. (Bug #18497308)

• Setting default_storage_engine to a bad value could cause server failure later. (Bug #18487724)

• In debug builds, MAKE_SET() within a GROUP BY clause raised an assertion. (Bug #18487060)

• In debug builds, subquery optimization could be overly aggressive about raising an assertion. (Bug #18486607)

• In debug builds, a qsort operation on decimal values could raise an assertion. (Bug #18486249)

• For debug builds, an assertion was raised for attempts using a cursor within a stored routine to fetch a large value (INT) which cannot fit into a variable (TINYINT). (Bug #18484649)

• MOD for very small decimal right-hand arguments could cause a server exit. (Bug #18469276)

• With the max_heap_table_size system variable set to a large value (20GB), creation of a temporary table or a table using the MEMORY storage engine caused a server exit. (Bug #18463911)

• mysql_session_track_get_first() and mysql_session_track_get_next() returned information only when the type argument was SESSION_TRACK_SYSTEM_VARIABLES, and returned information for all types, not just SESSION_TRACK_SYSTEM_VARIABLES. Now they return information of the type requested and only that type. (Bug #18463441)

• For mysql_upgrade, specifying the --defaults-extra-file with a nonexisting file caused a segmentation fault on some platforms. (Bug #18443096)

• Assigning some values to the session_track_system_variables system variable could cause a server exit. (Bug #18405677)

• mysql_install_db could hang while reading /dev/random to generate a random root password. (Bug #18395378)

• EXPLAIN FOR CONNECTION showed an incorrect filtering value for dynamic range queries. (Bug #18395059)

• The client library now includes a call to X509_verify_cert_error_string() in the SSL certificate verification code, to be more robust in detecting invalid certificates. (Bug #18384260)

• Queries that use AES_ENCRYPT(), AES_DECRYPT(), or RANDOM_BYTES() cannot be cached but were permitted to enter the query cache. (Bug #18383169)

• If MySQL was built with the -DINSTALL_LIBDIR=lib64 option, mysql_config did not work if the MySQL package was unpacked into a location with a different installation prefix. Also, mysql_config did not work for some RPM builds because it used an incorrect installation prefix. (Bug #18382225)

• Plugin registration code in the embedded server (compiled without the Performance Schema) failed for plugins compiled with the Performance Schema. (Bug #18363910)

• For indexes on prefixes or character string columns, index corruption could occur for assignment of binary data to the column due to improper character counting. (Bug #18359924)

• The HAVE_IB_LINUX_FUTEX CMake check failed due to a missing include file. (Bug #18353271)

• After a code reorganization in MySQL 5.7.4, ORDER BY for multiple-table UPDATE statements was ignored. (Bug #18352634)

• The addition in MySQL 5.7.4 of session state information to the OK packet of the client/server protocol caused the mysql->info member to be missing a terminating null terminator. (Bug #18349102)

• Improper linking of join caches by the optimizer could lead to a server exit. (Bug #18335908)

• In debug builds, lack of proper object initialization of decimal objects caused an assertion to be raised. (Bug #18335446)

• UNCOMPRESSED_LENGTH() could return NULL when it should not have. (Bug #18335269)

• On Windows, some test cases ran too slowly due to mysqltest not testing properly for server termination. (Bug #18330694)

• The COM_RESET_CONNECTION command did not reset some session system variables: rand_seed1, rand_seed2, timestamp. Also, it did not clear warnings, and, although it reset the profiling variable, it did not reset profiling information. (Bug #18329348, Bug #18329560, Bug #18328396, Bug #18329452)

• Certain INFORMATION_SCHEMA queries could cause a server exit. (Bug #18319790)

• EXPLAIN for some full-text queries could raise an assertion. (Bug #18313651)

• Solaris-specific scripts were included in and installed by non-Solaris packages. (Bug #18305641)

• DELETE is not allowed on views defined as joins on the base tables. However, MySQL incorrectly permitted REPLACE (which is like a combination of DELETE and INSERT) on such views. (Bug #18286777)

• For debug builds, a 0x00 character in a full-text query string that used the ujis_japanese_ci, utf8mb4_turkish_ci, or eucjpms_bin collation could raise an assertion. (Bug #18277305)

• innobase_strnxfrm() wrote one byte too many. (Bug #18277082)

• On Windows, use of the gb18030_unicode_520_ci caused a server exit. (Bug #18271429)

• The internal likely() and unlikely() macros conflicted with Boost symbols. To resolve this, the macros were converted to inline functions. (Bug #18242233)

• If the left-hand-side of an IN predicate was a scalar subquery but returned no row, the server could exit. (Bug #18223655, Bug #18447874)

• For queries involving an AND of two geometry ranges, the optimizer could decide no index was usable but try to use it anyway, resulting in a server exit. (Bug #18220153)

• Argument checking for a memmove() call in my_net_read() was improved. (Bug #18184793)

• mysql_upgrade invoked the mysql and mysqlcheck clients and the command arguments could be visible to other processes. This issue is addressed by the reimplementation of mysql_upgrade to communicate directly with the server, a change described elsewhere in these release notes. (Bug #18180398)

• yaSSL code had an off-by-one error in certificate decoding that could cause buffer overflow.

  yaSSL code had an opendir() without a corresponding closedir(). (Bug #18178997, Bug #17201924)

• EXPLAIN on a query with an EXISTS subquery containing a UNION could cause a server exit. Multiple executions of a prepared EXPLAIN on a UNION of subqueries could cause a server exit. (Bug #18167356)

• mysqladmin password masked the old password given on the command line, but not the new password. (Bug #18163964)

• For InnoDB tables, boolean full-text queries for terms ending with * could return incorrect results. (Bug #18128757)

• For XA transactions, -1 could be assigned as the format ID part of an XID value, resulting in mishandling (server hang or exit) of concurrent XA statements. (Bug #18107853)

• The client library could cause clients to exit due to incorrectly mapping the client error number to the corresponding message, if reallocation of packet buffer memory occurred. (Bug #18080920)

• For full-text queries on InnoDB tables, attempts to access deleted document IDs could lead to a server exit. (Bug #18079671)

• The optimizer could compute a negative cost value when constructing an execution plan for MERGE table queries. (Bug #18066518)

• Executing a correlated subquery on an ARCHIVE table which has an AUTO_INCREMENT column caused the server to hang. (Bug #18065452)

• Calling mysql_get_server_version() with an invalid connection handler argument caused the client to exit. Now it returns 0 and reports a CR_COMMANDS_OUT_OF_SYNC error. (Bug #18053212)

• MyISAM temporary files could be used to mount a code-execution attack. (Bug #18045646)

• If the optimizer chose to perform an index scan, in some cases it could choose a noncovering rather than a covering index. (Bug #18035906)

• The CMake -DWITHOUT_PARTITION_STORAGE_ENGINE=1 option did not work. As part of fixing this problem, a preferred syntax for disabling storage engines was implmented. The syntax -DWITH_engine_STORAGE_ENGINE=0 is now preferred to -DWITHOUT_engine_STORAGE_ENGINE=1. For example, use:

  -DWITH_EXAMPLE_STORAGE_ENGINE=0
  -DWITH_FEDERATED_STORAGE_ENGINE=0
  -DWITH_PARTITION_STORAGE_ENGINE=0

  Rather than:

  -DWITHOUT_EXAMPLE_STORAGE_ENGINE=1
  -DWITHOUT_FEDERATED_STORAGE_ENGINE=1
  -DWITHOUT_PARTITION_STORAGE_ENGINE=1

  (Bug #17947926)

• The C client library could leak memory when client plugins were used. (Bug #17933308)

• For debug builds, DROP FUNCTION with a too-long function name raised an assertion. (Bug #17903490)

• A BEFORE UPDATE trigger could insert NULL into a NOT NULL column. (Bug #17864349)

• A UNION ALL query with SQL_CALC_FOUND_ROWS and a LIMIT with an offset for one query block reported an incorrect number of found rows. (Bug #17833261)

• For debug builds, a DELETE statement with a subquery that returned multiple rows in a context requiring a scalar subquery could raise a diagnostic area assertion. (Bug #17787664)

• Using an outer reference in a GROUP BY or ORDER BY clause in a subquery could cause a server exit. (Bug #17748273)

• For queries that selected from the events_statements_current Performance Schema table, adding an ORDER BY clause could produce incorrect results. (Bug #17729044)

• A (rare) deadlock could occur between LOCK_thd_data and the InnoDB trx_sys mutex. One thread could read a query string while it was being removed by another thread. (Bug #17606098)

• On Windows, calling mysql_thread_init() call without mysql_init() caused the client to exit. windows. Now it returns a nonzero result because it is an error to call mysql_thread_init() before the client library is initialized with mysql_library_init(). (Bug #17514920)

• For REPLACE on a view, a row being replaced in a view might conflict with one or more rows in the base table, some of which might not be accessible by the view. In some cases, rows inaccessible by the view could be replaced. (Bug #17487701)

• mysqldump could create table definitions in the dump file that resulted in Too many columns errors when reloading the dump file. (Bug #17477959)

• Using LOAD DATA to load fixed-length data into a view could cause a server exit. (Bug #17458965)

• The optimizer trace could cause a server exit in cases where a subquery was transformed away. (Bug #17458054)

• UPDATE statements that modified full-text indexes could cause a server exit. (Bug #17457755)

• Sending a SIGQUIT or SIGINT signal to mysql could result in a glibc double free or corruption error. (Bug #17297324)

• A server could have its socket file taken over by a second server listening on different TCP/IP port but the same socket file. The socket file also would be unlinked by normal shutdown of the second server. To avoid this, the server now uses a lock file with the same name as the socket file and a .lock suffix. (For example, /tmp/mysql.sock has a lock file of /tmp/mysql.sock.lock.) The lock file contains the process ID of the server process that created the socket file. (Bug #17286856)

• If a query had both MIN()/MAX() and aggregate_function(DISTINCT) (for example, SUM(DISTINCT)) and was executed using Loose Index Scan, the result values of MIN()/MAX() were set improperly. (Bug #17217128)

• For UNION statements, the rows-examined value was calculated incorrectly. This was manifest as too-large values for the ROWS_EXAMINED column of Performance Schema statement tables (such as events_statements_current). (Bug #17059925)

• When joining one large table without indexes to a number of smaller tables with indexes, the optimizer chose to join on the large table as the last table, causing a large number of large table scans. (Bug #16838146)

• Row constructor arguments to INTERVAL() could cause a server exit. (Bug #16439419)

• An assertion could be raised when creating a index on a prefix of a TINYBLOB or GEOMETRY column in an InnoDB column. (Bug #16368875, Bug #18776592, Bug #17665767)

• mysql_config_editor left some files open when they were no longer needed, resulting in Valgrind warnings. (Bug #16368498)

• Several issues related to the ONLY_FULL_GROUP_BY SQL mode were corrected:

  • With ONLY_FULL_GROUP_BY enabled, some valid queries were rejected if the accessed table was replaced by a view.

  • Queries of the form SELECT DISTINCT col1 ... ORDER BY col2 qualify as forbidden by SQL2003 (hidden ORDER BY columns combined with DISTINCT), but were not rejected with the ONLY_FULL_GROUP_BY SQL mode enabled.

  (Bug #16021396, Bug #18993257, Bug #13581713)

• The change made in MySQL 5.7.0 to display the XID value in hexadecimal for XA RECOVER if it contained nonprintable characters was reverted because it caused problems for some clients. Now the statement takes an optional CONVERT XID keyword so that clients can request the XID value in hexadecimal on demand. (Bug #14670465)

• Use of a nonmultibyte algorithm for skipping leading spaces in multibyte strings could cause a server exit. (Bug #12368495, Bug #18315770)

• Executing a DELETE statement on a table with no key in safe-update mode resulted in an ER_UPDATE_WITHOUT_KEY_IN_SAFE_MODE error. For debug builds, using IGNORE in the statement resulted in an assertion being raised. (Bug #74493, Bug #19873291)

• Binary MySQL distributions for OS X 10.8 and up now bundle the MySQL.prefPane and MySQLStartupItem.pkg tools into the main package as configurable options instead of separate packages. (Bug #74123, Bug #19701502)

• For debug builds, a SELECT under load from the events_statements_current Performance Schema table could raise an assertion. (Bug #73530, Bug #19419463)

• mysql_secure_installation failed to run properly if the root account authentication plugin was sha256_password. (Bug #73148, Bug #19127636)

• The server did not take the lower_case_table_names value into account in determining the database directory from which to read the db.opts file, and thus could read the file from an incorrect directory. (Bug #72900, Bug #18923685)

• SHA2() failed to return NULL if the hash-length argument was NULL or not one of the permitted values. (Bug #72856, Bug #18899869)

• mysql_install_db failed to create the initial root account if autocommit was disabled. (Bug #72724, Bug #18911807)

• The mysql client displayed gb18030 data incorrectly. (Bug #72573, Bug #18726196)

• The gb18030_chinese_ci collation treated 'Y' equal to '~'. (Bug #72565, Bug #18729428)

• The query cache was not invalidated for a table when a CASCADE DELETE or CASCADE UPDATE referential constraint was specified and the database name or table name contained special characters. (Bug #72547, Bug #18710853)

• NOW(N) in a view definition was stored as NOW(), thus losing the fractional seconds part. (Bug #72472, Bug #18675237)

• If a prepared statement being executed produced an error, the server failed to write the statement to the general query log. (Bug #72375, Bug #18616826)

• A new CMake option, SUNPRO_CXX_LIBRARY, enables linking against libCstd instead of stlport4 on Solaris 10 or later. This works only for client code because the server depends on C++98. Example usage:

  cmake -DWITHOUT_SERVER=1 -DSUNPRO_CXX_LIBRARY=Cstd

  (Bug #72352, Bug #18605389)

• A SELECT statement using a subquery with UNION and ORDER BY did not permit use of an alias in the outer statement. (Bug #72189, Bug #18498344)

• UNION queries with an aggregate function in an ORDER BY clause were not rejected as they should be. Now such queries are rejected with an ER_AGGREGATE_ORDER_FOR_UNION error. Example:

  SELECT 1 AS foo UNION SELECT 2 ORDER BY MAX(1);

  A nonaggregated query with an ORDER BY applied to it cannot contain aggregate functions, but was not rejected as it should be. Now such queries are rejected with an ER_AGGREGATE_ORDER_NON_AGG_QUERY error. Example:

  SELECT a FROM t1 ORDER BY COUNT(*);

  (Bug #72174, Bug #18503515, Bug #72512, Bug #18694751)

• MOD operations on a DECIMAL value with leading zeros could produce incorrect results. (Bug #72100, Bug #18509896)

• mysqlslap accepted an --iterations option value of 0, which resulted in a divide-by-zero error. The minimum option value now is 1. Thanks to Tsubasa Tanaka for the patch. (Bug #72082, Bug #18430704)

• mysql_upgrade could fail if the mysql.user table contained multiple accounts with the same user name and host name where the host name differed in lettercase. This is still not permitted, but now mysql_upgrade prints a more informative error message to indicate the nature of the problem:

  ERROR 1644 (45000): Multiple accounts exist for user_name, host_name
  that differ only in Host lettercase; remove all except one of them

  (Bug #72066, Bug #18415196)

• ER_CANT_CREATE_GEOMETRY_OBJECT was treated as a fatal error, thus not catchable with condition handlers. (Bug #72064, Bug #18413646)

• Some comparisons between BIGINT signed and unsigned values could yield incorrect results. (Bug #72046, Bug #18408499)

• For IN() predicates with values different from the key data value, the optimizer sometimes used a table scan when it could do a range scan. (Bug #71962, Bug #18364815)

• mysql_config_editor exited when given an empty argument to the --login-path option. (Bug #71837, Bug #18311024, Bug #18830493)

• Upgrades using RPM packages could change the ownership of an installation directory. (Bug #71715, Bug #18281535)

• The threads Performance Schema table displayed a PROCESS_ID value of NULL for replication threads. Now it displays the same ID as SHOW PROCESSLIST and the INFORMATION_SCHEMA.PROCESSLIST table. (Bug #71682, Bug #18259356)

• In the DIGEST_TEXT column of Performance Schema statement events tables, references to system variables of the form @@var_name were stored as @ @ var_name. (Bug #71634, Bug #18304086)

• For mysqldump, dump and restore operations failed for database names that contained backslash ('\'). Thanks to Xiaobin Lin for the patch. (Bug #71437, Bug #18109728)

• A simultaneous OPTIMIZE TABLE and online ALTER TABLE on the same InnoDB table could result in deadlock. (Bug #71433, Bug #18110156)

• XA START after a server restart with the exising XID followed by XA COMMIT failed to commit. (Bug #71352, Bug #18068253)

• Proxy users were unable to execute statements if the proxied user password had expired. (Bug #71337, Bug #18057562)

• MySQL did not compile with Bison 3. (Bug #71250, Bug #18017820, Bug #18978946)

• Deadlock could occur if three threads simultaneously performed INSTALL PLUGIN, SHOW VARIABLES, and mysql_change_user(). (Bug #71236, Bug #18008907, Bug #72870, Bug #18903155)

• A statement of the following form broke row-based replication because it created a table having a field of data type BIGINT with a display width of 3000, which is beyond the maximum acceptable value of 255:

  CREATE TABLE t1 AS SELECT REPEAT('A',1000) DIV 1 AS a;

  (Bug #71179, Bug #17994219)

• When MySQL runs as service on Windows, NTService.Stop() initiates shutdown and exit events during shutdown. After a code reorganization in MySQL 5.7.3, a call to clean_up() was missed, resulting in initiation of crash recovery. (Bug #71104, Bug #17980260)

• If there was a predicate on a column referenced by MIN() or MAX() and that predicate was not present in all the disjunctions on key parts earlier in the compound index, Loose Index Scan returned an incorrect result. (Bug #71097, Bug #17909656)

• Invalid memory access could occur when using prepared statements if a mysql client connection was lost after statement preparation was complete and there was at least one statement that was in initialized state but not prepared yet. (Bug #70429, Bug #17512527)

• Client auto-reconnect did not work for clients linked against libmysqlclient, even with MYSQL_OPT_RECONNECT enabled.

  Also, if a FEDERATED table was accessed after wait_timeout expired, a Lost connection to MySQL server error occurred without an attempt to re-establish the connection. (Bug #70026, Bug #17309863, Bug #14874, Bug #11745408)

• Full-text queries on MyISAM tables that included a LIMIT clause but no WHERE clause could return too few rows. (Bug #69908, Bug #17261347)

• Updates could fail to update all applicable rows in cases where multiple key values were identical except for trailing spaces. (Bug #69684, Bug #17156940)

• On Windows, REPAIR TABLE and OPTIMIZE TABLE failed for MyISAM tables with .MYD files larger than 4GB. (Bug #69683, Bug #17235179)

• For logging of prepared statements to the general query log, the Execute line was logged after statement execution, not before. (Bug #69453, Bug #16953758, Bug #20536590)

• Calls to UNCOMPRESS() produced Valgrind warnings during verification of the zip header of the compressed data. (Bug #69202, Bug #18693654)

• mysql_tzinfo_to_sql mishandled some values from the abbreviation list (read from the timezone information file) due to failure to account for the null character appended to the end of the char array. (Bug #68861, Bug #16664462)

• Some statements could be written to the slow query log twice. (Bug #68626, Bug #16467055)

• File permissions and line endings of several test and configuration files were made more consistent to avoid warnings from package checkers. (Bug #68521, Bug #16415173, Bug #16395459, Bug #68517, Bug #16415032, Bug #71112, Bug #17919313, Bug #71113, Bug #17919422)

• In some cases, a successful CREATE VIEW could add invalid parentheses to expressions in the view definition. (Bug #67791, Bug #15948263)

• If the general query log or slow query log file was set to a FIFO or socket file, and the file reader went away, the server stopped executing statements. Now the server detects such files, logs an error message, and continues with the appropriate log disabled. (Bug #67088, Bug #14757009)

• For non-debug builds of several client programs, the --help message did not correctly indicate that the --debug, --debug-check, and --debug-info apply only for debug builds. (Bug #66854, Bug #16272328)

• Notification of events for the general log were received by the audit log plugin only if the general query log was enabled. Now notifications are posted regardless of whether the general query log is enabled. (Bug #60782, Bug #12368204, Bug #20536590, Bug #75796, Bug #20479643)

• Queries that used GROUP BY INSERT() could produce spurious duplicate-key errors. (Bug #58081, Bug #11765149)

• mysql_install_db could fail if not invoked in the MySQL installation base directory. (Bug #54034, Bug #11761529)

• With big_tables enabled, queries that used COUNT(DISTINCT) on a simple join with a constant equality condition on a non-duplicate key returned incorrect results. (Bug #52582, Bug #11760197)

  References: See also: Bug #18853696.

• LOAD DATA LOCAL could use all CPU if import errors occurred when there were no line delimiters. (Bug #51840, Bug #11759519)

• For an existing nondynamic (built-in) plugin, the error message for an attempted UNINSTALL PLUGIN was misleading (the plugin does not exist). Now the message indicates that built-in plugins cannot be uninstalled. (Bug #51771, Bug #11759453)

• LIKE matches failed for code points of HALF WIDTH KATAKANA in the sjis and cp932 character sets. (Bug #47641, Bug #11755818)

• The server failed to produce an error for INSERT statements that provided no column names but did provide column values. (Bug #20943, Bug #11745889, Bug #18064775)

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

• Connection IDs are 32-bit unsigned integers, beginning at 1. When the server assigns connection IDs and reaches the top of the 32-bit range, it rolls the value over to begin at 1 again. It was possible that the server would assign a connection ID to a new thread while that ID was still in use by an existing thread, if the old thread was particularly long running. For such cases, reference to the ID becomes ambiguous. For example, it cannot reliably be determined for KILL connection_id which thread to kill, which could lead to undefined behavior. This behavior has been corrected so that in-use IDs are not reused. (WL #7293)