MySQL :: MySQL 8.0 Release Notes :: Changes in MySQL 8.0.17 (2019-07-22, General Availability)

MySQL 8.0 Release Notes / Changes in MySQL 8.0.17 (2019-07-22, General Availability)

Changes in MySQL 8.0.17 (2019-07-22, General Availability)

For general information about upgrades, downgrades, platform support, etc., please visit https://dev.mysql.com/doc/relnotes/mysql/8.0/en/.

Audit Log Notes

Encryption and decryption operations for encrypted MySQL Enterprise Audit log files use a password stored in the MySQL keyring. Previously, only a single password was stored. Generating a new password made the old password inaccessible, rendering MySQL Enterprise Audit unable to read log files encrypted with the old password. MySQL Enterprise Audit now implements password history in the keyring, which includes password archiving and expiration capabilities. The audit log plugin includes in each encrypted log file name the ID of the password required to read the file. To enable expiration and removal of old archived passwords in the keyring, the new audit_log_password_history_keep_days system variable is available. See Configuring Audit Logging Characteristics. (WL #11246)

C API Notes

These C API changes were made:
- HOSTNAME_LENGTH was changed from 60 to 255 and moved from include/mysql_com.h to include/my_hostname.h.
- USER_HOST_BUFF_SIZE was moved from include/mysql_com.h to sql/auth/auth_common.h.
(Bug #29590300)

Character Set Support

The utf8mb4 character set has a new binary collation, utf8mb4_0900_bin, which differs from the existing utf8mb4_bin binary collation as follows:
- For collating weights, utf8mb4_bin uses code points, possibly with leading zero bytes added, whereas utf8mb4_0900_bin uses the utf8mb4 encoding bytes. The sort order is the same for both collations, but sorting for utf8mb4_0900_bin is much faster.
- The pad attribute for utf8mb4_bin is PAD SPACE, whereas for utf8mb4_0900_bin it is NO PAD. Consequently, operations involving utf8mb4_0900_bin do not add trailing spaces, and comparisons involving strings with trailing spaces may differ for the two collations.
For more information, see Unicode Character Sets. (WL #10354)

Component Notes

A new mysql_current_thread_reader component service is available to enable components to obtain a handle to the current thread. For example, the service enables components to access properties of the current session by passing its thread handle to other services. For information about this service, see the Component Subsystem section of the MySQL Server Doxygen documentation, available at https://dev.mysql.com/doc/index-other.html. (WL #12727)

Configuration Notes

The source files in the mysys_ssl directory have been moved to the mysys directory and the mysys_ssl library is no longer built. (Bug #29488066)
MySQL configuration now requires a minimum CMake version of 3.5.1. (Bug #29337090)
The maximum permitted length of host names throughout MySQL has been raised to 255 ASCII characters, up from the previous limit of 60 characters. This applies to, for example, host name-related columns in the data dictionary, mysql system schema, Performance Schema, INFORMATION_SCHEMA, and sys schema; the MASTER_HOST value for the CHANGE MASTER TO statement; the Host column in SHOW PROCESSLIST statement output; host names in account names (such as used in account-management statements and in DEFINER attributes); and host name-related command options and system variables.

Caveats:
- The increase in permitted host name length can affect tables with indexes on host name columns. For example, tables in the mysql system schema that index host names now have an explicit ROW_FORMAT attribute of DYNAMIC to accommodate longer index values.
- Some file name-valued configuration settings might be constructed based on the server host name. The permitted values are constrained by the underlying operating system, which may not permit file names long enough to include 255-character host names. This affects the general_log_file, log_error, pid_file, relay_log, and slow_query_log_file system variables and corresponding options. If host name-based values are too long for the OS, explicit shorter values must be provided.
- Although the server now supports 255-character host names, connections to the server established using the --ssl-mode=VERIFY_IDENTITY option are constrained by maximum host name length supported by OpenSSL. Host name matches pertain to two fields of SSL certificates, which have maximum lengths as follows: Common Name: maximum length 64; Subject Alternative Name: maximum length as per RFC#1034.
Applications that expect host names to be a maximum of 60 characters should be adjusted to account for this change. (Bug #13548245, Bug #63814, Bug #27925782, Bug #90601, Bug #27955121, Bug #29584642, Bug #29602081, Bug #94907, WL #12571)

Debugging Notes

The MySQL server is a multithreaded application that uses numerous internal locking primitives such as mutexes. To enable detection of lock-acquisition deadlocks and enforcement that runtime execution is free of them, MySQL now supports LOCK_ORDER tooling. This enables a lock-order dependency graph to be defined as part of server design, and server runtime checking to ensure that lock acquisition is acyclic and that execution paths comply with the graph. LOCK_ORDER support includes:
- A lock_order_dependencies.txt file that defines the server lock-order dependency graph.
- A WITH_LOCK_ORDER CMake option that configures whether MySQL is built with LOCK_ORDER tooling.
- A set of system variables that configure LOCK_ORDER tool operation during server execution.
- A --lock-order option for mysql-test-run.pl that controls whether to enable the LOCK_ORDER tool during test case execution.
To use the LOCK_ORDER tool, you must build MySQL from source with tooling enabled. See The LOCK_ORDER Tool. It is intended for debugging the server, not for production use.

Deprecation and Removal Notes

X DevAPI: For Collection objects, the following methods have been deprecated and are scheduled to be removed in a future release:
- Collection.find().where()
- Collection.modify().where()
- Collection.remove().where()
Any Collection code relying on the .where() method should be updated and the expression in the .where() method should be provided directly in the appropriate .find(), .remove(), and .modify() method. (WL #12902)
A mysql_upgrade_info file created by the mysql_upgrade program during a previous upgrade could only be modified the operating system user that executed the mysql_upgrade program, causing an upgrade error. A warning is now issued instead of an error, which permits the upgrade operation to proceed. The mysql_upgrade_info file is deprecated and will be removed in a future MySQL version. (Bug #29702060, Bug #95165)
FLOAT(M,D) and DOUBLE(M,D) syntax to specify the number of digits for columns of type FLOAT and DOUBLE (and any synonyms) is a nonstandard MySQL extension. This syntax is deprecated and support for it will be removed in a future MySQL version. (Bug #25328973, Bug #84363, WL #12575)
For string data types, the BINARY attribute is a nonstandard MySQL extension that is shorthand for specifying the binary (_bin) collation of the column character set (or of the table default character set if no column character set is specified). In MySQL 8.0, this nonstandard use of BINARY is ambiguous because the utf8mb4 character set has multiple _bin collations, so the BINARY attribute is deprecated and support for it will be removed in a future MySQL version. Applications should be adjusted to use an explicit _bin collation instead.

The use of BINARY to specify a data type or character set remains unchanged. (WL #13068)
The nonstandard C-style &&, ||, and ! operators that are synonyms for the standard SQL AND, OR, and NOT operators, respectively, are deprecated and support for them will be removed in a future MySQL version. Applications that use the nonstandard operators should be adjusted to use the standard operators.

Note

Use of || is deprecated unless the PIPES_AS_CONCAT SQL mode is enabled. In that case, || signifies the SQL-standard string concatenation operator).

(WL #13070)
The ZEROFILL attribute is deprecated for numeric data types, as is the display width attribute for integer data types. Support for ZEROFILL and display widths for integer data types will be removed in a future MySQL version. Consider using an alternative means of producing the effect of these attributes. For example, applications could use the LPAD() function to zero-pad numbers up to the desired width, or they could store the formatted numbers in CHAR columns. (WL #13127)
The UNSIGNED attribute is deprecated for columns of type FLOAT, DOUBLE, and DECIMAL (and any synonyms) and support for it will be removed in a future MySQL version. Consider using a simple CHECK constraint instead for such columns. (WL #12391)
AUTO_INCREMENT support is deprecated for columns of type FLOAT and DOUBLE (and any synonyms) and will be removed in a future MySQL version. Consider removing the AUTO_INCREMENT attribute from such columns, or convert them to an integer type. (WL #12595)
The SQL_CALC_FOUND_ROWS query modifier and accompanying FOUND_ROWS() function are now deprecated and will be removed in a future MySQL version. As a replacement, considering executing your query with LIMIT, and then a second query with COUNT(*) and without LIMIT to determine whether there are additional rows. For example, instead of these queries:
```
SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name WHERE id > 100 LIMIT 10;
SELECT FOUND_ROWS();
```
Use these queries instead:
```
SELECT * FROM tbl_name WHERE id > 100 LIMIT 10;
SELECT COUNT(*) WHERE id > 100;
```
COUNT(*) is subject to certain optimizations. SQL_CALC_FOUND_ROWS causes some optimizations to be disabled. (WL #12615)

Installation Notes

An automatic upgrade at server startup can take some time to complete. For better status notification in systemd environments, the server now sends messages to the system notification socket when upgrades start and end. (Status can be monitored with server mysqld status.) (Bug #29493201)

Keyring Notes

The keyring_aws plugin has been updated to use the latest AWS Encryption SDK and so that it works with OpenSSL 1.1.

The keyring_aws_region variable supports the additional AWS regions supported by the new SDK. Refer to the variable description for a list of supported AWS regions. (WL #12886)

Packaging Notes

To reduce the download size and disk footprint of mysql-community-server Linux packages, debug binaries and plugins have been moved to separate packages for these platforms:
- EL8, Fedora: The mysql-community-server package with debug binaries and associated plugins is now split into a mysql-community-server package without debug binaries or plugins and a mysql-community-server-debug package with debug binaries and plugins.
- Debian: The mysql-community-server package with debug binaries and associated plugins is now split into a mysql-community-server package without debug binaries or plugins, a mysql-community-server-debug package with debug binaries, and a mysql-community-test-debug package with debug plugins.
In all cases, the debug packages are dependent on the corresponding mysql-community-server package. (Bug #29769061, Bug #28647754, Bug #92415, Bug #29702765, Bug #95169, Bug #29681301)

Performance Schema Notes

Performance Schema version checking at compile time was improved to prevent incompatibilities with the server version. (Bug #29550156)
Previously, the Performance Schema instrumentation for RWLOCK named priority read/write locks as rwlock (thus failing to distinguish plain from priority locks) and did not collect information about the kind of unlock operation performed. Priority read/write locks now are named prlock, so that events for them begin with wait/synch/prlock. Also, information about unlock operations is provided. (Bug #29270712)

Plugin Notes

Not all plugins can operate properly if loaded “early” in the server startup sequence using the --early-plugin-load option (that is, before InnoDB is initialized). However, InnoDB requires keyring backend plugins to operate on encrypted tables. To enable plugins to indicate to the server whether they can be loaded early, a new PLUGIN_OPT_ALLOW_EARLY flag is available for use in the plugin descriptor. See Server Plugin Library and Plugin Descriptors. Keyring plugins included in MySQL distributions now have the PLUGIN_OPT_ALLOW_EARLY flag enabled because InnoDB requires them, but the flag is not limited to keyring plugins. It can be set for other plugins that are able to initialize successfully early in the server startup sequence.

This flag has no effect on whether a plugin can be loaded at server startup with the --plugin-load or --plugin-load-add option, or at runtime with the INSTALL PLUGIN statement.

All plugins compiled using MySQL distributions prior to 8.0.17 do not have this flag set. When loading these into pre-8.0.17 servers this does not matter, but attempts to use --early-plugin-load to load plugin binaries compiled using pre-8.0.17 MySQL distributions into a 8.0.17 or higher server will fail. The plugins must be recompiled against MySQL 8.0.17 or higher. (Bug #29040456, Bug #93550, WL #12935)

Security Notes

For platforms on which OpenSSL libraries are bundled, the linked OpenSSL library for MySQL Server has been updated to version 1.0.2s. Issues fixed in the new OpenSSL version are described at https://www.openssl.org/news/cl102.txt and https://www.openssl.org/news/vulnerabilities.html. (Bug #29881152)

X Plugin Notes

The createIndex() method did not support the DOUBLE(M,D) syntax for specifying double-precision values due to a regression in MySQL 8.0.16. (Bug #29748841)
X Protocol's handling of messages with arguments encoded as octets was corrected to support non-scalar data such as an array of strings. (Bug #29721046)
When host name identity verification was active for SSL connections (--ssl-mode=VERIFY_IDENTITY), X Protocol did not check for matches to Subject Alternative Names (SANs) in the server Certificate Authority (CA) certificate. This could lead to connection requests being rejected unnecessarily because they used a valid host name that was specified as an SAN rather than as the certificate's Common Name value. (Bug #29691694)
When prepared statements were used with X Plugin, using IN or NOT IN in a modify or find operation produced invalid JSON, resulting in an error. (Bug #29259501)
On Windows, X Plugin logged some messages that were unnecessary or insufficiently informative. The messages have been removed or improved as appropriate. (Bug #27839153)
X Plugin's list of SQL functions was out of date, and has been updated to add new functions and remove functions that are no longer available. (Bug #26574971)

Functionality Added or Changed

InnoDB; JSON: InnoDB now supports multi-valued indexes on JSON arrays. A multi-valued index is an index in which multiple index records can point to the same data record. This can be useful for indexing JSON documents such as {"user":"Bob","zipcode":[94477,94536]} in which, if we wish to search all zip codes, it is necessary to have two index records for each zip code in the document. We can create such an index on the zipcode array using a CREATE INDEX statement such as this one:
```
CREATE INDEX zips ON t1( (CAST(data->'$.zipcode' AS UNSIGNED ARRAY)) )
```
Effectively, this is a functional index using the CAST() function, which has been extended with the ARRAY keyword to enable casting of JSON arrays to SQL data type arrays. The expression must be a valid JSON expression, and must point to an array in the JSON document in order to be effective. All type specifiers supported by CAST() can be used except for BINARY and JSON. Such usage of the CAST() function is supported only by InnoDB, and only for creating multi-valued indexes on JSON arrays.

As part of this work, MySQL adds a new function JSON_OVERLAPS() as well as a new MEMBER OF() operator for working with JSON documents, as described here:
- JSON_OVERLAPS() compares two JSON documents. If they contain any key-value pairs or array elements in common, the function returns TRUE (1); otherwise it returns FALSE (0). If both values are scalars, the function performs a simple test for equality. If one argument is a JSON array and the other is a scalar, the scalar is treated as an array element. Thus, JSON_OVERLAPS() acts as a complement to JSON_CONTAINS(), which indicates whether all key-value pairs or array elements are present in both JSON documents.
- MEMBER OF() tests whether the first operand (a scalar or JSON document) is a member of the JSON array passed as the second operand, returning TRUE (1) if it is, and FALSE (0) if it is not. No type conversion of the operand is performed.
The MySQL optimizer uses multi-valued indexes automatically for any suitable query—that is, a query using in its WHERE clause any of JSON_CONTAINS(), JSON_OVERLAPS(), or MEMBER OF() on an array within a JSON column. You can see whether such an index is actually used by checking the output of EXPLAIN for the given query.

Multi-Valued Indexes, provides more detailed information about multi-valued indexes, including examples. For more information about JSON_OVERLAPS() and MEMBER OF(), with examples of use, see Functions That Search JSON Values.

Note

ARRAY and MEMBER now are reserved words and cannot be used as identifiers without identifier quoting.

(WL #8955, WL #8763)
Group Replication: It is now possible to use a remote cloning operation for state transfer to a joining member during distributed recovery. The remote cloning operation lets you add new members to the group without transferring the group's data to the server manually beforehand. To use this functionality, you must install the Clone plugin on the donor and joining member, grant the BACKUP_ADMIN permission to the replication user for distributed recovery, and set the new group_replication_clone_threshold system variable to an appropriate level. Required Clone plugin settings are now made and the remote cloning operation is now handled automatically. When cloning is complete and the joining member has restarted, any transactions that the group applied while the remote cloning operation was in progress are transferred to the joining member by replication from a donor's binary log to complete distributed recovery. (WL #12827)
Microsoft Windows: A new warning message now reminds DBAs that connections made using the MySQL named pipe on Windows has limited the permissions a connector can request on the named pipe.

Previously, the named_pipe_full_access_group system variable was set to a value that maps to the built-in Windows Everyone group (SID S-1-1-0) by default. However, this group is not ideal and should be replaced with a group that restricts its membership for connectors that are unable to request fewer permissions on the MySQL named pipe.

The new warning is written to the error log at startup if the string value assigned to named_pipe_full_access_group is '*everyone*' (or the Windows System Language equivalent) and named pipes are enabled. In addition, the warning is written to the error log and raised to the client if the system variable is reset to the Everyone group at runtime. (WL #12670)
JSON: MySQL now supports JSON schema validation using two functions JSON_SCHEMA_VALID() and JSON_SCHEMA_VALIDATION_REPORT(), both of which validate a JSON document against a JSON schema conforming to Draft 4 of the JSON Schema specification. JSON_SCHEMA_VALID() returns true if the document validates against the schema and false if it does not. JSON_SCHEMA_VALIDATION_REPORT() returns a JSON document containing detailed information about the results of the validation.

For both of these functions, the following statements apply:
- required attributes are supported.
- Regular expressions are supported (invalid expressions are silently ignored).
- External resources in schemas and the $ref keyword are not supported.
For more information, including examples, see JSON Schema Validation Functions. (WL #11999, WL #13005)
The time_zone session variable is now hintable using the SET_VAR optimizer hint. (Bug #29776464)
The minor version of the libmysqlclient.so C client library has been increased to 1 (21.0 to 21.1), to signal that new symbols have been added. This was done to correct an oversight in the MySQL 8.0.16 release. To address compatibility concerns, the version of all symbols is unchanged. This means the filename of the library is libmysqlclient.so.21.1.17, whereas all symbols inside the library are tagged as 21_0 (unchanged from the 8.0.16 release). (Bug #29584073, Bug #29642146)
Thanks to Josh Braden, Daniël van Eeden, Simon Mudd, and Zhou Mengkang, who contributed corrections to comments and messages in the MySQL source code. (Bug #29403708, Bug #94464, Bug #29428435, Bug #94527, Bug #29262200, Bug #94049, Bug #29468128, Bug #94625)
The mysql client program now sends os_user and os_sudouser connection attributes, when available, to indicate the name of the operating system user running the program and the value of the SUDO_USER environment variable, respectively. For general information about connection attributes, see Performance Schema Connection Attribute Tables. Thanks to Daniël van Eeden for the contribution on which this feature was based. (Bug #29210935, Bug #93916, WL #12955)
The optimizer now transforms a WHERE condition having NOT IN (subquery), NOT EXISTS (subquery), IN (subquery) IS NOT TRUE, or EXISTS (subquery) IS NOT TRUE internally into an antijoin, thus removing the subquery. This is similar to the existing IS NULL (Not exists) outer join optimization; see EXPLAIN Extra Information, for further information.

In addition, the semijoin materialization can now be used for a WHERE condition having IN (subquery) IS TRUE, or EXISTS (subquery) IS TRUE, or when the IN condition belongs to a left join such as SELECT * FROM t1 LEFT JOIN t2 ON t2.x IN (SELECT * FROM t3). See Optimizing IN and EXISTS Subquery Predicates with Semijoin Transformations.

Also as a result of this work, MySQL is now able to simplify a condition of the form (x IS TRUE) IS FALSE as x IS NOT TRUE, which can be tested more quickly and optimized more easily than the condition as originally written. (Bug #29027883, WL #4245)
Password hash values displayed in the IDENTIFIED WITH clause of output from SHOW CREATE USER may contain unprintable characters that have adverse effects on terminal displays and in other environments. Enabling the new print_identified_with_as_hex system variable causes SHOW CREATE USER to display such hash values as hexadecimal strings rather than as regular string literals. Hash values that do not contain unprintable characters still display as regular string literals, even with this variable enabled. For compatibility with this change, CREATE USER and ALTER USER now accept hash values specified either as regular string literals or as hexadecimal strings. (Bug #28053446, Bug #90947, WL #12803)
In MySQL 8.0, the lower_case_table_names variable can only be configured when the MySQL server is initialized. Because a MySQL server installation on Debian and Ubuntu performed using APT initializes the MySQL server for you, there was no opportunity to enable lower_case_table_names. To work around this issue, you can now use the debconf-set-selection utility to enable lower_case_table_names (set lower_case_table_names=1) prior to installing MySQL using APT.

To enable lower_case_table_names prior to installing MySQL using APT, execute the following command:
```
shell> sudo debconf-set-selections <<< "mysql-server mysql-server/lowercase-table-names select Enabled
```
(Bug #27948395, Bug #90695)
The server now checks the SSL server certificate better at startup and writes a warning to the error log if it finds a problem. (Bug #25945005)
The umask for files created using SELECT ... INTO OUTFILE or SELECT ... INTO DUMPFILE was changed from 0666 to 0640. The LOAD_FILE() function no longer requires files to be world-readable, just readable by the server. (Bug #24513720)
The mysqldump option --set-gtid-purged controls whether or not a SET @@GLOBAL.gtid_purged statement is added to the mysqldump output. The statement updates the value of gtid_purged on a server where the dump file is reloaded, to add the GTID set from the source server's gtid_executed system variable. A new choice --set-gtid-purged=COMMENTED is now available. When this value is set, if GTIDs are enabled on the server you are backing up, SET @@GLOBAL.gtid_purged is added to the output (unless gtid_executed is empty), but it is commented out. This means that the value of gtid_executed is available in the output, but no action is taken automatically when the dump file is reloaded. With COMMENTED, you can control the use of the gtid_executed set manually or through automation. For example, you might prefer to do this if you are migrating data to another server that already has different active databases. Thanks to Facebook for this contribution. (Bug #94332, Bug #29357665, WL #12959)
MySQL now supports explicit casts to DOUBLE, FLOAT, and REAL using either of the functions CAST() or CONVERT(). For more information, see Cast Functions and Operators. (Bug #30524, Bug #11747058, WL #529)
InnoDB now supports redo log archiving. Backup utilities that copy redo log records may sometimes fail to keep pace with redo log generation while a backup operation is in progress, resulting in lost redo log records due to those records being overwritten. The redo log archiving feature addresses this issue by sequentially writing redo log records to an archive file. Backup utilities can copy redo log records from the archive file as necessary, thereby avoiding the potential loss of data.

For more information, see Redo Log Archiving. (WL #12009, WL #12329, WL #12348)
To provide additional indexing options for JSON data, InnoDB now supports multi-valued indexes. A multi-valued index is a secondary index defined on a column that contains an array of values. (WL #8763)
MySQL now provides a clone plugin that permits cloning InnoDB data locally or from a remote MySQL server instance. A local cloning operation stores cloned data on the same server or node where the MySQL instance runs. A remote cloning operation transfers cloned data over the network from a donor MySQL server instance to the recipient server or node where the cloning operation was initiated.

The clone plugin supports replication. In addition to cloning data, a cloning operation extracts and transfers replication coordinates from the donor and applies them on the recipient, which enables using the clone plugin for provisioning Group Replication members and replication slaves. Using the clone plugin for provisioning is considerably faster and more efficient than replicating a large number of transactions. Group Replication members can also be configured to use the clone plugin as an alternative method of recovery, so that members automatically choose the most efficient way to retrieve group data from seed members.

For more information, see The Clone Plugin, and Cloning for Distributed Recovery. (WL #9209, WL #9210, WL #9211, WL #9212, WL #11636, WL #9682)
Compatibility policies for member versions in groups now consider member's MySQL release version. Previously, only the minor version was considered. Using the release version means Group Replication can better maintain replication safety for mixed version groups during group reconfigurations and upgrade procedures.

The compatibility policies are applied when a member joins the group, either for the first time or following its upgrade, when a donor is selected for state transfer, and when a primary member election takes place. Members running MySQL 8.0.16 or earlier take into account only the major version in these situations. For primary member election, so that all members come to the same decision, members running MySQL 8.0.17 or later adjust their policies to match members running lower releases if any are in the group.

In a multi-primary mode group where members running multiple MySQL Server versions are online, for example during a rolling online upgrade procedure, Group Replication now automatically manages the read-write and read-only status of members running releases. If a member leaves the group, the members running the version that is now the lowest are automatically set to read-write mode. When you change a mixed version group that was running in single-primary mode to run in multi-primary mode, using the group_replication_switch_to_multi_primary_mode() function, members are set automatically to read-write or read-only mode depending on their MySQL server versions.

These improved compatibility policies influence the behavior of group members during an online upgrade procedure from one patch version to another, in the same ways as the behavior during upgrades from one major version to another was influenced previously. For a multi-primary mode group, the number of members in read-write mode is reduced during the upgrade procedure; their read-write status is now handled automaticaly when the upgrade is otherwise complete. For a single-primary mode group, if you want the primary to remain as the primary, it must be upgraded last. (WL #12826)
Data that is held in the binary log transaction and statement caches during a transaction is in unencrypted format in the memory buffer that stores the cache. The data is written to a temporary file on disk if it exceeds the space available in the memory buffer. From MySQL 8.0.17, when binary log encryption is active on the server (binlog_encryption=ON), the temporary files used for the binary log cache are now encrypted using AES-CTR (AES Counter mode) for stream encryption. Because the temporary files are volatile and tied to a single process, they are encrypted using single-tier encryption, using a randomly generated file password and initialization vector that exist only in memory and are never stored on disk or in the keyring. After each transaction is committed, the binary log cache is reset: the memory buffer is cleared, any temporary file used to hold the binary log cache is truncated, and a new file password and initialization vector are randomly generated for use with the next transaction. This reset also takes place when the server is restarted after a normal shutdown or an unexpected halt. (WL #12079)
An incomplete SQL predicate has the form WHERE value, in which value is a column name or constant expression and no comparison operator is used. MySQL now rewrites any predicate of this type internally as WHERE value <> 0 during the contextualization phase, so that the query resolver, query optimizer, and query executor need work only with complete predicates. The principal visible effect of this change is that, for Boolean values, EXPLAIN output now shows true and false, rather than 1 and 0. (WL #12358)
InnoDB parallel read thread performance for large data sets was improved through better utilization of read threads, through a reduction in read thread I/O for prefetch activity that occurs during parallel scans, and through support for parallel scanning of partitions.

The parallel read thread feature is controlled by the innodb_parallel_read_threads variable. The maximum setting is now 256, which is the total number of threads for all client connections. If the thread limit is reached, connections fall back to using a single thread. (WL #12978)
mysqlbinlog now supports the --compress (or -C) option to enable compression in the client/server protocol. (WL #2726)

Bugs Fixed

NDB Cluster: Compile times for NDB Cluster using the included compile_cluster build script have been improved by removing options for software components not strictly necessary for running MySQL Cluster. (Bug #29355872)
NDB Cluster: Attempting to change an NDB table's column properties (such as COLUMN_FORMAT) using ALTER TABLE ALGORITHM=INPLACE was rejected, which is correct behavior, but which raised a misleading error message. (Bug #28929906, Bug #27645777)
InnoDB: A failure occurred when attempting to kill a process that was executing a row count. (Bug #29939617)
InnoDB: Due to a regression introduced in MySQL 8.0.14, in-place upgrade on a case sensitive file system from MySQL 5.7 or a MySQL 8.0 release prior to MySQL 8.0.14 to MySQL 8.0.16 failed for instances with partitioned tables and lower_case_table_names=1. The failure was caused by a case mismatch issue related to partitioned table file names. The fix that introduced the regression was reverted, which permits upgrades to MySQL 8.0.17 from MySQL 5.7 or MySQL 8.0 releases prior to MySQL 8.0.14 to function as normal. However, the regression is still present in the MySQL 8.0.14, 8.0.15, and 8.0.16 releases.

In-place upgrade on a case sensitive file system from MySQL 8.0.14, 8.0.15, or 8.0.16 to MySQL 8.0.17 fails with the following error when starting the server after upgrading binaries or packages to MySQL 8.0.17 if partitioned tables are present and lower_case_table_names=1:
```
Upgrading from server version version_number with
partitioned tables and lower_case_table_names == 1 on a case sensitive file
system may cause issues, and is therefore prohibited. To upgrade anyway,
restart the new server version with the command line option 'upgrade=FORCE'.
When upgrade is completed, please execute 'RENAME TABLE part_table_name
TO new_table_name; RENAME TABLE new_table_name
TO part_table_name;' for each of the partitioned tables.
Please see the documentation for further information.
```
If you encounter this error when upgrading to MySQL 8.0.17, perform the following workaround:
1. Restart the server with --upgrade=FORCE to force the upgrade operation to proceed.
2. Identify partitioned table file names with lowercase partition name delimiters (#p# or #sp#):
```
SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES
    WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
```
3. For each file identified, rename the associated table using a temporary name, then rename the table back to its original name.
```
mysql> RENAME TABLE table_name TO temporary_table_name;
mysql> RENAME TABLE temporary_table_name TO table_name;
```
4. Verify that there are no partitioned table file names with lowercase partition name delimiters (an empty result set should be returned).
```
mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES
    ->     WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
Empty set (0.00 sec)
```
5. Run ANALYZE TABLE on each renamed table to update the optimizer statistics in the mysql.innodb_index_stats and mysql.innodb_table_stats tables.
Because of the regression still present in the MySQL 8.0.14, 8.0.15, and 8.0.16 releases, importing partitioned tables from MySQL 8.0.14, 8.0.15, or 8.0.16 to MySQL 8.0.17 is not supported on case sensitive file systems where lower_case_table_names=1. Attempting to do so results in a “Tablespace is missing for table” error. (Bug #29823032, Bug #29917793, Bug #95834)

References: This issue is a regression of: Bug #26925260.
InnoDB: lock_sys mutex contention caused by lock-wait functions (lock_wait_suspend_thread() and lock_wait_table_release_slot()) was reduced. (Bug #29814339)
InnoDB: The fseg_n_reserved_pages_low() function, which determines the number of pages reserved by a segment, did not validate results read from the segment inode. (Bug #29761998)
InnoDB: Creation of the transaction rollback list (hit_list) was decoupled from lock acquisition calls (lock_rec_lock calls) to permit the use of different latching schemes. (Bug #29753800)
InnoDB: Disabling Performance Schema consumers caused an ALTER TABLESPACE ... ENCRYPTION operation to assert. (Bug #29646974, Bug #95005)
InnoDB: Error messages were revised to remove references to .frm files, which are not used in MySQL 8.0. (Bug #29639655)
InnoDB: It was possible for a background thread to check the encryption status of an undo tablespace before the undo tablespace was fully initialized and the encryption flag set. (Bug #29600309)
InnoDB: A table name parsing function call returned false when parsing serialized dictionary information (SDI) tables names, which are not formatted to include a database name. The buffer that holds the database name remained uninitialized, causing Valgrind errors. (Bug #29550527)
InnoDB: The space reserved in the mini-transaction (mtr) log buffer for dynamic metadata logging was insufficient. (Bug #29524260)
InnoDB: Inaccuracies in the Contention-Aware Transaction Scheduling (CATS) implementation raised a signed integer overflow error in an UBSan build of MySQL. (Bug #29508517, Bug #91959)
InnoDB: Insufficient memory barriers in the rw-lock implementation caused deadlocks on ARM.

Thanks to Yibo Cai from Arm Technology for the contribution. (Bug #29508001, Bug #94699)
InnoDB: The INFORMATION_SCHEMA.INNODB_TABLESPACES ENCRYPTION column was not updated after enabling undo tablespace encryption. (Bug #29492911, Bug #94665)
InnoDB: A relocated table could not be accessed due to incorrect parsing of a schema or table name that included a forward slash character (/), which the server incorrectly interpreted as a directory separator. (Bug #29492113)
InnoDB: Various fixes and revisions were applied to the InnoDB memcached source code. (Bug #29485891)
InnoDB: To enable global access, the value of innodb_directories variable is now stored internally as a global variable instead of a static variable. (Bug #29471990)
InnoDB: In debug builds, the thd_innodb_tmpdir() function did not accept a NULL argument. (Bug #29471846)
InnoDB: A subtraction operation in the file space allocation code incorrectly stored the result as an unsigned variable, which raised an assertion failure. (Bug #29466680)
InnoDB: After moving or deleting default undo tablespaces and restarting the server with a new innodb_undo_directory value, MySQL recreated the undo tablespaces in the new location but failed to update the undo directory path in the data dictionary. (Bug #29461900)
InnoDB: A previously freed LOB page was accessed while rolling back a transaction during recovery. (Bug #29440408)
InnoDB: A request was issued during recovery to read pages into the buffer pool when there were no pages to be read. A check was added to avoid the unnecessary read request. (Bug #29440208)
InnoDB: A regression introduced in MySQL 8.0.14 caused a “Invalid (old?) table or database name” error when creating a partitioned table on a MySQL instance with lower_case_table_names=1. The change that caused the regression has been reverted. (Bug #29426720, Bug #94519)

References: This issue is a regression of: Bug #26925260.
InnoDB: A FULLTEXT index table created in MySQL 5.6 in a database with a hyphen in its name caused a startup failure after upgrading from MySQL 5.7 to MySQL 8.0. Tablespace file paths for FULLTEXT auxiliary tables were not found in the data dictionary, and the hyphen in the database name was not handled correctly in subsequently generated file paths. (Bug #29411899, Bug #94431)
InnoDB: There was potential for data loss to occur if the redo log was not logically empty and comprised a single block, and the server exited during recovery after an insert buffer merge generated new redo records but before the new records could be flushed to disk. (Bug #29411832, Bug #94448)
InnoDB: InnoDB returned an unknown generic error when attempting to create a tablespace for which the path and file name exceeded the MAX_PATH limit on Windows. InnoDB now returns a more meaningful error. (Bug #29341634)
InnoDB: An undo tablespace file was not found after being moved to a different directory. (Bug #29328158)
InnoDB: The server failed to start with an innodb_buffer_pool_size=default setting. The default value was not checked for compatibility with dependent system variable settings. (Bug #29267814, Bug #94065)
InnoDB: The CREATE TABLESPACE ... ADD DATAFILE clause no longer permits circular directory references. For example, the circular directory reference (/../) in the following statement is not permitted:
```
CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd 'any_directory/../ts1.ibd';
```
An exception to this restriction exists on Linux, where a circular directory reference is permitted if the preceding directory is a symbolic link. For example, the data file path in the example above is permitted if any_directory is a symbolic link. (It is still permitted for data file paths to begin with '../'.)

To avoid upgrade issues, remove any circular directory references from tablespace data file paths before upgrading to MySQL 8.0.17 or higher. To inspect tablespace paths, query the INFORMATION_SCHEMA.INNODB_DATAFILES table. (Bug #29157265)
InnoDB: Manually changing the system time while the MySQL server was running caused page cleaner thread delays. (Bug #29138644, Bug #93708)
InnoDB: UPDATE statements did not always disable semi-consistent reads properly when encountering errors, which could lead to assertion errors in debug mode. (Bug #29047894)
InnoDB: When purging a deleted row, the logic that governs lock inheritance did not correctly determine the type of lock that should be inherited to satisfy constraint checks by active transactions. (Bug #29004362)
InnoDB: An unnecessary read lock was taken on implicitly opened data dictionary tables when executing a prepared statement in LOCK TABLES mode. (Bug #28875646)
InnoDB: During log application, after an OPTIMIZE TABLE operation, InnoDB did not populate virtual columns before checking for virtual column index updates. (Bug #28834208)
InnoDB: An operation that copied data from the clustered index was performed incorrectly, causing spatial indexes to use spatial rows with stale pointers to the clustered index. (Bug #28758961)
InnoDB: An INSERT operation involving a generated virtual BLOB column resulted a secondary index being updated with an incorrect value. (Bug #28652826)
InnoDB: Configuring innodb_data_file_path and innodb_temp_data_file_path using SET PERSIST_ONLY = default incorrectly set the variable values to NULL. (Bug #28590014)
InnoDB: A CREATE TABLE ... REPLACE SELECT operation raised a lock_rec_get_rec_not_gap(lock) assertion failure. The operation set a flag on the transaction object indicating that a REPLACE operation was requested, but did not clear the flag before updating dependent views, causing a subsequent INSERT operation to be interpreted as a REPLACE operation, leading to the wrong row locks being taken. (Bug #28523025, Bug #92068)
InnoDB: With super_read_only enabled, an attempted RENAME TABLE operation on a temporary table raised an assertion instead of returning an error. (Bug #28490368, Bug #91975)
InnoDB: Valgrind errors were reported due to uninitialized bytes read during a virtual index prefix search. (Bug #28184025)
InnoDB: InnoDB initialization failed when attempting to create an system tablespace greater than 2GB in size. (Bug #27538464)
InnoDB: A full-text cache lock taken when data is synchronized was not released if the full-text cache size exceeded the full-text cache size limit. (Bug #25289359)
InnoDB: The INNODB_METRICS metadata_table_reference_count counter reported a negative value. (Bug #20584149, Bug #75966)
InnoDB: Client sessions using different auto_increment_increment values while performing concurrent insert operations could cause a duplicate key error. (Bug #15851528, Bug #67526)

References: Reverted patches: Bug #14049391, Bug #65225.
Partitioning: For partitioned tables, an ALTER TABLE statement could cause incorrect query results under these conditions:
- The statement swapped columns by renaming them, either directly with RENAME COLUMN or by replacement with DROP COLUMN/ADD COLUMN.
- A swapped column was used in a partitioning expression.
- The alteration was performed as an in-place operation that did not redistribute rows between partitions.
Such column renames are now prohibited unless the same ALTER TABLE statement satisfies one of these conditions:
- The statement makes the table nonpartitioned.
- The statement redefines the table partitioning or partitioning expression (which causes a table rebuild that redistributes rows). This enables supporting existing scenarios in which partitioning expressions are updated to follow column renaming.
- Partitioning is specified using PARTITION BY KEY() with an empty column list. This partitions using the primary key, which tracks column renaming.
(Bug #29541665, Bug #94792)
Partitioning: ALTER TABLE ... EXCHANGE PARTITION failed with the error Non matching attribute 'ROW_FORMAT' between partition and table when the partitioned table had partitions using different row formats, even when the partition to be exchanged used the same row format as the non-partitioned table. (Bug #28687608)
Replication: When events generated by one MySQL server instance were written to the binary log of another instance, the second server implicitly assumed that the first server supported the same number of binary log event types as itself. Where this was not the case, the event header was handled incorrectly. The issue has now been fixed. Thanks to Facebook for the contribution. (Bug #29417234, Bug #94500)
Replication: If a LOCK INSTANCE FOR BACKUP statement was used to acquire an instance-level backup lock, then a STOP SLAVE statement was issued, a deadlock could be created with the SQL thread waiting on the backup lock and the STOP SLAVE statement waiting on the SQL thread to complete its current action. To prevent this situation, the STOP SLAVE process now tries to acquire the backup lock before proceeding, and returns an error if the lock cannot be acquired. (Bug #29386503, Bug #93649)
Replication: From MySQL 8.0.13, if any replication channel has open temporary tables, the binary logging format cannot be changed using SET @@global.binlog_format or SET @@persist.binlog_format. Previously, if this operation was attempted after the new restriction was implemented, the wrong error message was returned to the client (referencing a running replication channel applier as the issue, rather than an open temporary table). The appropriate error message is now returned. (Bug #29370024, Bug #94340)
Replication: Binary log checksums were handled incorrectly when de-serializing a format description event. (Bug #29355110)
Replication: With row-based replication in use, when the replication applier thread unpacked a row change event, index values for any functional indexes were calculated for both the “before” image and the “after” image. In the case of the “before” image, the values were not necessary. This calculation has therefore been removed for the before image in order to optimize row unpacking. (Bug #29304076)
Replication: When a MEMORY table is implicitly deleted on a master following a server restart, the master writes a DELETE statement to the binary log so that slaves also empty the table. This generated event now includes a comment in the binary log so that the reason for the DELETE statement is easy to identify. Thanks to Daniël van Eeden for the contribution. (Bug #29157796, Bug #93771)
Replication: If an invalid starting offset was provided in a SHOW BINLOG EVENTS FROM statement, the invalid offset was returned in place of the correct starting position for the first returned event. (Bug #29039732, Bug #93544)
Replication: Replication could stop with a “record not found” error when the value INDEX_SCAN,HASH_SCAN (the default in MySQL 8.0) was set for the slave_rows_search_algorithms system variable, and an update event contained two updates to the same row in a table that did not have a unique key, meaning that the hash scan was used. In this situation, the second update was missed by the hash scan due to the row change. Now, after updating a row, the hash scan operation searches for the updated row in the hash map, and applies any further update.

When the value TABLE_SCAN,HASH_SCAN is set for the slave_rows_search_algorithms system variable, so that the search cannot use an index, the “record not found” error can occur in the above situation whether or not the table has a unique key. Also, with this setting, when a hash scan is used on a table that has a unique key, in the case of an update event containing two row updates that are order-dependent, the updates might be applied out of order, causing replication to stop with a duplicate key error. To avoid these issues, the documentation has been updated to state that the value TABLE_SCAN,HASH_SCAN should not be used. (Bug #28846386)
Replication: When binary logging is enabled on a replication slave, the combination of the --replicate-same-server-id and --log-slave-updates options on the slave can cause infinite loops in replication if the server is part of a circular replication topology. (In MySQL 8.0, binary logging is enabled by default, and slave update logging is the default when binary logging is enabled.) However, the use of global transaction identifiers (GTIDs) prevents this situation by skipping the execution of transactions that have already been applied. The restriction on this combination of options has therefore now been removed when gtid_mode=ON is set. With any other GTID mode, the server still does not start with this combination of options. As a safeguard against creating the problem situation after the server has started, you now cannot change the GTID mode to anything other than ON on a running server that has this combination of options set. Thanks to Facebook for the contribution. (Bug #28782370, Bug #92754)
Replication: In query log events in the binary log, the thread ID used for the execution of DROP TABLE and DELETE statements was identified incorrectly or not at all. On a multi-threaded replication slave, where temporary tables were involved (which require the correct thread ID as they are session specific), this omission resulted in errors when using mysqlbinlog to replay the binary log for point-in-time recovery. The thread ID is now set correctly. (Bug #28642318, Bug #92398)
Replication: When a trigger invoked an INSERT or UPDATE statement that set a column to its default value, and the DEFAULT expression of that column was non-deterministic, the expected warning was not raised when the trigger fired under statement-based replication. In addition, if the binary logging format was MIXED, the non-deterministic statements were logged in the format used for STATEMENT rather than that used for ROW.

The statement that causes the trigger to fire checks at resolution time whether any of the triggered statements are non-deterministic. At this time, the triggered statements have been parsed, but not resolved, so the only check that can be performed is whether the triggered statements directly reference any non-deterministic operators. When the non-deterministic operator is used by a DEFAULT expression, the non-determinism is not visible until the triggered statement has been resolved, which happens when the trigger fires.

This is fixed by adding an extra check when determining the logging format, where a statement is flagged as unsafe if any of its substatements can write to a table that has a column with a non-deterministic DEFAULT expression. Since it is not yet known at this point whether the DEFAULT expression will be used by the substatement, this check flags the statement as unsafe even if the substatement provides an explicit value for the column with a non-deterministic DEFAULT expression. (Bug #28297486)
Replication: When a slave server logs master status and connection information to a table (master_info_repository=TABLE), which is the default in MySQL 8.0, the mysql.slave_master_info table was not being updated on shutdown if the server was in super read only mode (super_read_only=ON). No error was written to the error log at this time, but replication failed after server startup because the master log file and master log position information was out of date. The thread that updates the master info log at shutdown is now excluded from read-only checks like other replication threads are, so it can update the table even if the server is in super read only mode. Error handling for a slave that is shutting down has also been improved so that any failure to write to the slave status logs results in an error in the error log. (Bug #27675107, Bug #89987)
Replication: If a replication slave tried to connect to the master using an incorrect user name, host, or port, the original error message specifying the reason for the connection failure was overwritten with a generic message. The issue has now been corrected in the output from the SHOW SLAVE STATUS statement and in the Performance Schema table replication_connection_status. (Bug #26580064)
Group Replication: When message fragmentation is in use for large Group Replication messages (which is available, and the default, from MySQL 8.0.16), if a fragmented message sent by the group member with the highest node identifier in XCom was partially delivered, and one or more members then left the group prior to the delivery of the remaining message fragments, reassembly of the message caused Group Replication to stop working. The loss of members meant that the node identifier of the original sender was no longer valid in the new view of the group. To correct this issue, reassembly of fragmented messages now uses the delivery information from the last fragment that was delivered, which reflects the new situation after the view change, rather than from the first fragment that was delivered, which reflects the old situation before the view change. (Bug #29716639)
Group Replication: The error message that is issued for a discrepancy between the number of group members and the auto-increment interval incorrectly referred to the group_replication_auto_increment_increment system variable, instead of the auto_increment_increment system variable. The value of auto_increment_increment is changed to the value specified by group_replication_auto_increment_increment when Group Replication starts, but only if auto_increment_increment and auto_increment_offset have their default values, and from MySQL 8.0, only in multi-primary mode. The value of auto_increment_increment was always the value that was checked for the error message, and it has now been corrected to give the accurate system variable name. (Bug #29542425)
Group Replication: Group Replication cannot be started following a MySQL Server upgrade that uses the MINIMAL option (--upgrade=MINIMAL), which does not upgrade system tables on which this feature depends. Previously, in this situation, the server waited indefinitely for Group Replication to start. This is now handled correctly by unblocking the waiting thread and issuing the expected error ER_GRP_RPL_START_GRP_RPL_FAILED. (Bug #29423358, Bug #94515)
Group Replication: A change in the processing of suspicions by a member that is leaving the group meant that recovery failed because due to a circular dependency between the recovery failure and the view change notification. Now, if an error makes recovery impossible, the Group Communication System handles this as follows:
1. The member leaves the group
2. the view change is applied
3. The recovery thread is terminated.
(Bug #29417365, Bug #29628909)
Group Replication: In Group Replication, joining members could wrongly identify themselves as incompatible with an existing replication group even if there were members at the same version already in the group, because they checked against all other members, including the member at the highest version. Joining members also included their own version in the compatibility check. Now, joining members only compare themselves with the existing group member at the lowest version, and do not count their own version. (Bug #29390946, Bug #94429)
Group Replication: Functions for configuring an online group sometimes did not return an error when an issue arose during execution. These functions also now check whether the Group Replication plugin is stopping before they start to initialize. (Bug #28978767, Bug #93372)
Group Replication: The XCom group communication engine did not handle out of memory errors in an appropriate way. If memory could not be allocated to make a copy of the payload for a message, an error was logged but the message was still sent, with a null payload. The Group Communication System (GCS) on the receiving member discarded the message as empty, and the XCom instance on the receiving member accepted this action and did not retry, resulting in the message effectively being skipped. This caused the GTID set on the receiving member to diverge from the group, leading to replication errors. XCom now terminates gracefully if it experiences an out of memory error, so that this situation cannot occur. (Bug #28702320)
macOS: For macOS installations performed using DMG packages, launchd operation was problematic:
- Previously, SHUTDOWN caused a restart if MySQL was configured to start at boot time via the preference pane. This also affected the mysqladmin shutdown command. Server shutdown initiated in these ways now works correctly.
- Previously, RESTART did not work. It now works correctly.
- Previously, unexpected server exits did not cause automatic restart if the server was not configured to start at boot time. Exits with a nonzero exit status now cause a restart regardless of boot-time startup configuration.
(Bug #29789857)
JSON: MAX() and MIN() used on expressions returning JSON data sometimes compared these values as strings rather than JSON values, which caused unexpected results; this was particularly evident when the JSON values were numbers.

This was due to the fact that GROUP BY when using temporary tables with indexes did not compare JSON values correctly. (Bug #28947381)
JSON: JSON_TABLE() returned the error Unknown database '' when executed from a stored function.

The root cause of this issue was that, when merging tables from a select that used JSON_TABLE(), MySQL checked only for derived tables. This caused the result table returned by JSON_TABLE() to be noted as a regular table, so that when attempting to execute the query, the server failed to open it. Now MySQL checks whether the table to be added is not an internal table, that is, not a derived table, a JSON_TABLE() result table, or a reference to a recursive common table expression. (Bug #92976, Bug #28851656)
The WITH ADMIN option for GRANT statements sometimes was not handled properly. (Bug #29900772)
Some foreign key error messages could differ depending on whether the user had the GRANT OPTION privilege. (Bug #29868844)
During upgrade operations, upgrades of the help tables failed if autocommit was disabled. (Bug #29865428, Bug #95620)
Fetching dynamically allocated dictionary objects into a vector during upgrade while operating with a small table_open_cache size caused data dictionary tables to be reopened, triggering a garbage collection mechanism that incorrectly freed collected objects. Subsequent attempts to access the freed objects caused a segmentation fault. (Bug #29823053)
For upgrades from MySQL 5.7 to 8.0, the upgrade process did not close the innodb_*_stats_backup57.ibd files in the mysql system schema before removing them, resulting in errors for subsequent file system operations. (Bug #29791350)
mysqld --initialize would fail if the file system was mounted at the data directory mount point and a lost+found file or directory was present. The lost+found file or directory is now ignored during data directory initialization. (Bug #29780434)
MySQL upgrades did not assign the AUDIT_ADMIN privilege to accounts that had the SUPER privilege. (Bug #29770732)
The REGEXP_REPLACE() function did not handle empty strings correctly in all cases. (Bug #29763554)
An overly strict assertion could be raised during sorting of stored program local objects. (Bug #29759547, Bug #95062)
The group_replication_get_communication_protocol() function, which is used to query the group's communication protocol version, failed if any group members were in RECOVERING state, which was an unnecessary restriction. The function can now be used provided that the member where it runs is in ONLINE state, and is in contact with a majority of the group. (Bug #29754967, Bug #95306)
For some arguments to REPEAT(), maximum length calculations were not always handled correctly. (Bug #29739778)
UPDATE statements for tables with CHECK constraints could fail to enforce the constraints. (Bug #29706621, Bug #95189)
For installation from RPM or Debian packages, if the mysql_upgrade_info file in the data directory is found to exist but is owned by root, it is now changed to the same owner as the data directory. The correct SELinux file context is also set. (Bug #29704041)
Installing from RPM packages could result in an error log with incorrect permissions. (Bug #29702462)
A replication group member that was unable to contact a majority of the group before the group_replication_unreachable_majority_timeout setting was reached, and then exhausted the number of auto-rejoin attempts specified by the group_replication_autorejoin_tries system variable without successfully rejoining, was sometimes unable to carry out the action specified by the group_replication_exit_state_action system variable. The member tries to carry out the action using the current session, which sometimes failed. The member now ensures that the session is initialized before using it to connect to the server to carry out the exit state action. (Bug #29698754, Bug #95151)
When performing a upgrade, server-side SQL statements that update data dictionary tables used a non-default collation, causing an upgrade failure. (Bug #29697670, Bug #95144)
Starting the server with --skip-grant-tables and invoking ROLES_GRAPHML() could lead to a server exit. (Bug #29681975)
SELECT DISTINCT when using fixed-length keys did not deduplicate records properly in all cases. (Bug #29628699)
Client programs that used asynchronous C API functions could access freed memory after occurrence of a fatal error such as connection failure or receipt of a too-large packet. (Bug #29596244)
The ST_AsWKB() function could fail to perform proper error checking. (Bug #29594287)
For failed data directory initialization, the server could produce a message indicating that the directory could be removed, even if the server itself did not create it. The message now indicates that only files in the directory created by the server can be removed. (Bug #29594082, Bug #94880)
In MySQL 8.0, the keyring_encypted_file plugin could not read a file created by a MySQL 5.7 keyring_encypted_file plugin. (Bug #29588345)
In builds with Undefined Behavior Sanitizer enabled, runtime errors occurred in my_strtoll10_mb2() and val_decimal(). (Bug #29585648, Bug #29594951)
Some diagnostics produced by the server while checking grant table structure at startup were written as errors rather than warnings. (Bug #29558993)
The comp_err utility could read uninitialized data. (Bug #29550442)
Enabling audit log encryption could cause a server exit. (Bug #29549327)
RPM package obsoletes were updated to enable successful upgrades from MariaDB to MySQL on EL8. (Bug #29549127, Bug #29623146, Bug #29623201, Bug #29659212)
In a join of the form LEFT JOIN t ON column WHERE t.x=0 IS NOT TRUE, MySQL evaluated IS NOT TRUE as FALSE for a NULL argument in a null-complemented row, and rejected it. This caused an invalid conversion of the left join to an inner join, so that there were missing rows in the result. The same issue affected joins of the same form but having IS NOT FALSE in the WHERE condition. (Bug #29540230)
If the read_only system variable was enabled, its value improperly was applied against updates to the character set and collation data dictionary tables. (Bug #29533590, Bug #94769)
The functions STATEMENT_DIGEST() and STATEMENT_DIGEST_TEXT() used character_set_client while parsing the function's argument instead of the character set of the argument. (Bug #29526571)
The server now tracks data dictionary upgrades to ensure that INFORMATION_SCHEMA views are recreated when data dictionary tables are changed. (Bug #29513265)
Execution of STATEMENT_DIGEST() or STATEMENT_DIGEST_TEXT() could have unintended side effects on data in the performance_schema.events_statements_summary_by_digest table. (Bug #29512067)
The implementation for CREATE TABLE did not provide the table a clearly defined starting cursor when no seeks or writes were performed. (Bug #29511318)
When a table is const optimized, any predicate terms in the join's ON condition should also be evaluated on the tables marked as const to make sure that the row qualifies for the ON condition.

The optimizer failed to mark a table as const when it was handled as having an impossible ON condition, in which case the resulting row from this table is a NULL extended row.

This fix sets the const_table flag for the table and marks the row as a NULL row. It also changes EXPLAIN output for a table optimized as having an impossible ON condition, where the resulting NULL values from this row are now propagated into the rows column values, as with other const rows. (Bug #29493830)
A query containing an IN subquery could return superfluous rows when optimizer_switch did not include firstmatch=on. (Bug #29493026)
RPM package detection of whether the operating system is EL6 or EL7 failed on some systems. (Bug #29492896)
SQL layer validation of keys stored in storage-engine-private data fields in the data dictionary was disabled to permit storage engines to add new keys as required. Storage engines are now responsible for key validation. (Bug #29491593, Bug #94667)
Checks for NULL returned an incorrect result for some expressions comparing rows. (Bug #29491083)
When optimizing a table join which included ORDER BY and LIMIT, the optimizer modified the select limit on the first table by taking the fanout of the entire join into consideration. The fanout was calculated using the filter_effect for each table, which can be set to COND_FILTER_STALE (-1) to indicate an unknown value. This value was not actually checked for by the optimizer, which could result in a negative fanout, leading to an unexpected rows value of 0 in the EXPLAIN output for the query.

Now COND_FILTER_STALE (filter_effect unknown) is specifically checked for, and, if it is found, the fanout is also assumed to be unknown, and the number of rows to be selected from the first table is thus not modified by the fanout for the entire join. (Bug #29487181, Bug #29531472)
An implicit assumption was made for the LEAST() and GREATEST() functions that arguments to either of these were all signed or all unsigned values. (Bug #29467577)
Some arguments for the BIT_OR() function were not always handled correctly. (Bug #29459549)
For debug builds, mishandling of the user_attributes column of the mysql.user system table could cause a server exit. (Bug #29451897)
MySQL Cluster-specific Debian debug packages had an incorrect path to the debug symbols. (Bug #29446947)
Compilation failure occurred when building with Protobuf 3.7.0. (Bug #29436791, Bug #94543)
On Debian and Ubuntu, MySQL packages did not enable mysql.service after upgrades from native MySQL packages. (Bug #29435592)
The server did not properly close shared-memory connections when an error occurred, which could result in unexpected server behavior. (Bug #29435426)
The internal JOIN_CACHE::join_record() method attempted to leave all tables on which it operated in the same state with regard to the has_row and null_row flags by saving the state upon entry and restoring the appropriate flags when on completion.

The issue addressed here arose after these flags had been restored, due to the fact that restore_last_record() was also called to restore any records that had been processed, which could lead to setting back a null_row flag that had just been restored based on the saved state. This is fixed by calling restore_last_record() before the saved states are restored, rather than after, as well as making sure that reset_null_row() is also called if the saved state indicates that the null_row flag was not set at the beginning. (Bug #29435133)
Some ALTER TABLE statements using ADD COLUMN did not perform as expected. (Bug #29428288)

References: This issue is a regression of: Bug #28333657.
An incorrect error message was reported during upgrade from MySQL 5.7 to MySQL 8.0 when a non-natively partitioned table was encountered. The error message referenced the -DWITH_PARTITION_STORAGE_ENGINE CMake build option, which is not supported in MySQL 8.0. (Bug #29426632, Bug #94518)
At startup, the server did not properly check the length of user and host names in persisted variables. (Bug #29420141)
The parser could leak memory for certain multiple-statement queries. (Bug #29419820)
Installing MySQL on EL8 from RPM packages caused a conflict with the installed MeCab library. (Bug #29413115)
On FreeBSD, stack traces dumped for fatal signals did not work correctly. (Bug #29408039)
With the derived_merge switch disabled in the value of the optimizer_switch system variable, information retrieved for base tables from INFORMATION_SCHEMA.TABLES displayed inappropriate information in the TABLE_COMMENT column. (Bug #29406053, Bug #94468)
In certain cases, use of ORDER BY in a subselect did not produce the expected result. (Bug #29402943)
ROLLUP queries with wildcards (and probably also certain other wildcard queries) could cause assertion errors. (Bug #29396628)
A condition inside an IF function having a constant evaluating to TRUE was not always handled correctly. (Bug #29394833)
A code change in MySQL 8.0.13 related to full-text search caused a segmentation fault. (Bug #29393105)
mysqlpump did not check whether the argument to --result-file was opened correctly and exited unexpectedly if an error occurred. (Bug #29389828)
In queries without joins, batch mode was not enabled until after initialization was complete, so that OFFSET rows were read outside of batch mode. This negated any performance benefit to be had from batch mode. (Bug #29373972)
When renaming a functional index, the server did not check for a possible duplicate index name. (Bug #29360763)
The system variable service did not check the input buffer size for some operations. (Bug #29343505)
For mysql system schema dumps, mysqlpump dumped certain tables by row rather than as account-management statements. (Bug #29343073)
Creation of a functional index on a UNION subquery led to an assertion in debug builds. (Bug #29342245)
Non-numeric arguments to AVG() were not always handled correctly. (Bug #29321764)
Result sets with a very large number of columns could cause client programs to use all available memory. Now the client library allocates no more than max_allowed_packet bytes for result set metadata, returning an out-of-memory error if this limit is exceeded. If this error occurs, it is fatal and the client should disconnect. (Bug #29316814)
A call to mysql_shutdown() could cause the client to exit when the server and client were from different MySQL series, due to return packet payload misinterpretation. (Bug #29315393)
Client programs could fail while reading result set metadata if communicating with the server using the pre-MySQL 4.1 protocol. (Bug #29304864)
HANDLER statements did not always work correctly with tables having generated columns. (Bug #29300049)
Session-tracking information in the client/server protocol could be mishandled. (Bug #29297652)
Client programs that used the libmysqlclient C client library could exit upon receipt of an OK packet containing malformed session-tracking information. (Bug #29297620, Bug #29630735)
With the PAD_CHAR_TO_FULL_LENGTH SQL mode enabled, password changes failed, with no warning or error reported. (Bug #29287785)
Initialization code of loadable functions for the keyring_aws plugin did not properly check whether the plugin had been initialized. (Bug #29278153)
Scalar subqueries were not always identified and handled correctly when compared with aggregate or window functions. (Bug #29276063)
Ubuntu packages did not disable binary logging for initialization scripts. (Bug #29263771)
The internal collation map could become corrupted by use of invalid collation names. (Bug #29258979)
Single-table UPDATE and DELETE statements that used indexed expressions could cause the server to exit when executed as prepared statements. (Bug #29257254)
The audit_log plugin did not log UNINSTALL PLUGIN audit_log statements. (Bug #29248047)
MySQL now uses open(O_TMPFILE) whenever applicable when creating a temporary file that is immediately unlinked. This is more efficient than previously and avoids the small possibility of a race condition. Thanks to Daniel Black for the contribution. (Bug #29215177, Bug #93937)
audit_log filtering operations could leak memory. (Bug #29201747)
The GRANT OPTION privilege could be mishandled in some cases. (Bug #29179334)
Previously, LIKE comparisons could be incorrect if either of the _ or % SQL wildcard characters was used as the ESCAPE character. These characters can now be used. (Bug #29175461, Bug #93811)
The component_sys_variable service could fail to read certain system variables, causing a server exit. (Bug #29162657)
Multiple-table UPDATE statements could search for incorrect generated-column values when determining which row to update. (Bug #29154379)
If the server was started with Performance Schema parameters that caused an out-of-memory condition, startup failed. (Bug #29140212, Bug #93726)
For consistency and compliance with standard SQL, the ISNULL() function is now printed as IS NULL in warnings generated by EXPLAIN statements. (Bug #29119455)
Some supplemental Unicode characters could incorrectly be flagged with a warning message as invalid. (Bug #29110613, Bug #93626)
For upgrades from MySQL 5.7 to 8.0, the root user was not given all dynamic privileges. (Bug #29043233)
When using subpartitioning, table serialized dictionary information (SDI) was not stored in any tablespace file. (Bug #29020745, Bug #93499)
Privileges for dropping some Performance Schema tables were checked incorrectly. (Bug #29010031)
mysqldump failed to wrap SET NAMES utf8mb4 and SET character_set_client = utf8mb4 statements within version-specific comments, which could cause compatibility problems. (Bug #29007506, Bug #93450)
For a unique index created on one or more columns defined as NULL, the optimizer failed to handle joins using that index as eq_ref.

As part of this fix, late NULL filtering is now also performed to avoid treating comparisons with NULL as potential equality matches. (Bug #28965762, Bug #29337233)
For debug builds, an assertion could be raised by string comparisons for which the expected and actual collation differed. (Bug #28960901)
The server did not handle correctly a subquery which, prior to conversion to a semijoin, contained a merged derived table or common table expression which in turn had a WHERE clause with an outer reference against an indexed column. (Bug #28955216)
A query that employed a derived table which included an ORDER BY was not always handled correctly. (Bug #28942965)
When clients were terminated for inactivity exceeding the wait_timeout value, the message written to the error log was unclear. Now ER_NET_WAIT_ERROR is written, which is more specific about the cause of the problem. Thanks to Mattias Jonsson for the contribution. (Bug #28940167, Bug #93240)
Concurrent execution of FLUSH PRIVILEGES along with CREATE USER or ALTER USER could cause the server to stall. (Bug #28937018, Bug #93085)
CASE statement comparisons that relied on index prefix values could produce incorrect results. (Bug #28934315, Bug #93215)
When adjusting the query cost after sort elimination to compensate for sorts that had not been considered in the original cost estimate, and the estimates could sometimes be too low, or even negative.

The sort cost is added to the total cost in Optimize_table_order::consider_plan(), and subtracted from the total cost in JOIN::optimize() if it is found that sorting is not needed.

If consider_plan() finds that sorting is not needed, it does not add the sort cost to the total cost, but still records a sort cost in JOIN::sort_cost(), and this is set to the sort cost of the candidate plan considered previously. Later, JOIN::optimize() saw that the JOIN object had an associated sort cost, and subtracted that cost from the total cost, since it also sees that no sort is needed. Since the sort cost came from a candidate plan that was not the same as the chosen plan, the estimate was incorrect.

The fix is to make consider_plan() set JOIN::sort_cost to 0 if no sort cost is added to the total cost, so that the mistaken adjustment of the cost in JOIN::optimize() is not performed. (Bug #28884359)
Some GIS code failed to compile under Visual Studio 2017 15.5.6. (Bug #28861188)

References: This issue is a regression of: Bug #28842878.
Stored generated column values and indexes on virtual generated columns were not correctly updated after columns on which these generated columns depended were swapped using ALTER TABLE with RENAME COLUMN or CHANGE COLUMN.

Renaming of base columns for generated columns, generated defaults, and functional indexes is now prohibited unless the same ALTER TABLE statement satisfies one of these conditions:
- The statement removes the generated column, generated default, or functional index.
- The statement updates the dependent expression in question. This enables supporting existing scenarios in which generation expressions are updated to follow base column renaming.
Restrictions on dropping columns on which generated columns, generated defaults, or functional indexes depend were relaxed in a similar way. (Bug #28772251, Bug #92727)
Base columns were not excluded from index-only access by a generated column. (Bug #28652733)

References: See also: Bug #29664369. This issue is a regression of: Bug #23169112.
SET PERSIST_ONLY did not properly handle the version_tokens_session system variable. (Bug #28542569)
For debug builds, improper error checking for CREATE TABLE statements could cause an assertion to be raised. (Bug #28490361, Bug #91976)
MySQL 5.7 supported foreign keys on InnoDB tables with a parent key for which part of the referenced columns were hidden, but MySQL 8.0 did not. MySQL 8.0 now supports this capability. (Bug #28480149, Bug #91952)
INSERT ... ON DUPLICATE KEY UPDATE did not consider privileges granted by active roles. (Bug #28395115)
For unloaded components, component options specified at startup with a --loose- prefix were not processed if the component was later loaded at runtime. (Bug #28341329)
Long passwords solicited interactively by client programs could fail to be null-terminated. (Bug #28121400)
When building MySQL, CMake begins the process of downloading Boost by creating a zero-length tarball in the destination directory, which is removed when the download is complete. If the download was interrupted or timed out, the presence of this file prevented CMake from attempting to perform the download the time it was run. Now the zero-length tarball, if present, is removed before the download is started. (Bug #28089173)
A thread pool group could be blocked when a thread process tick time exceeded the maximum permitted value. The tick time now uses a larger data type to permit larger values. (Bug #28072609)
Privileges were not checked correctly for ALTER USER ... IDENTIFIED WITH ... BY. (Bug #27923149, Bug #29882299)
MySQL does not support OpenSSL session tickets, but did not set the SSL_OP_NO_TICKET flag to inform OpenSSL of that. The flag is now set. (Bug #27655493)
The audit_null plugin did not properly check for a null event record. (Bug #27638290)
UpdateXML() did not always free memory properly in certain cases. (Bug #27312862)
Empty values in the name column of the mysql.plugin system table caused the server to exit during startup. (Bug #27302459)
The server did not properly check privileges for CACHE INDEX statements. (Bug #26173827)
With the thread_pool plugin enabled, the Performance Schema status_by_thread table contained no data. (Bug #25933891)
The GRANT OPTION privilege was treated as related to database operations. (Bug #25203933, Bug #34159579)
REPAIR TABLE for ARCHIVE tables could result in a server exit. (Bug #23304911)
If an INSTALL PLUGIN statement contained invalid UTF-8 characters in the shared library name, it caused the server to hang (or to raise an assertion in debug builds). (Bug #14653594, Bug #23080148, Bug #27167197)
Logging to the mysql.slow_log system table could fail when values were to large for table columns. Now logging proceeds on a best-effort basis, writing what information can be provided. Otherwise, the row is discarded and a message is written to the error log. (Bug #11748692, Bug #37132)
A query using WHERE date_column LIKE 'year_value' failed with error 1525 Incorrect DATE value on Windows platforms. (Bug #95780, Bug #29904751)

References: This issue is a regression of: Bug #29368521.
A fix for a previous issue caused YEAR values to be treated as unsigned, but this did not allow for possible negative values arising during calculations involving subtraction, which could lead to data truncation errors. (Bug #95045, Bug #29668676)

References: This issue is a regression of: Bug #92209, Bug #28562930.
When working with derived tables with an aggregation which had zero input rows, the results of the aggregate functions were not properly copied into the temporary table. This caused incorrect results in cases where the derived table was evaluated multiple times, such as when performing a lateral join. (Bug #94721, Bug #29514504)
A window without a frame specification inheriting from a window with an ORDER BY yielded an incorrect result. (Bug #94251, Bug #29328529)
The results returned by the functions REGEXP_REPLACE() and REGEXP_SUBSTR() used UTF-16 rather than the character set and collation of the expression searched for matches. (Bug #94203, Bug #29308212)
A UNION ALL query with SUM(constant) was processed very slowly compared to the same query using SUM(column) instead. (Bug #93922, Bug #29227464)
JSON_OBJECTAGG() is non-deterministic in the presence of duplicate keys unless the window has ordering on the key, which is expected behavior, but a key-value pair that was no longer in the window frame still appeared in the result. (Bug #93822, Bug #29175262)
LIMIT was applied before HAVING in queries with subselects. (Bug #93214, Bug #28934388)

References: This issue is a regression of: Bug #25466100.
A query involving GROUP BY on a TIMESTAMP column resulted in a duplicate entry for key (ER_DUP_ENTRY) error. This problem arose when TIMESTAMP values were inserted into a table using a given setting for the time zone and these values were later fetched after the time zone setting had been changed, such that at least some of the inserted TIMESTAMP values occurred during the hour that the time changed from standard to daylight time (DST) in the new time zone, during which time the same TIMESTAMP value can exist twice. Now, when the server would otherwise return the error DUPLICATE ENTRY FOR KEY 'group_key', if the grouping involves a TIMESTAMP column, it instead raises the error Grouping on temporal is non-deterministic for time zones having DST. Please consider switching to UTC for this query.

In addition, it is suggested to set explicit_defaults_for_timestamp to ON as well as one or more of MODE_NO_ZERO_IN_DATE, MODE_NO_ZERO_DATE, or MODE_INVALID_DATES as part of the server SQL mode to help avoid this issue. (Bug #90398, Bug #27970159)

PREV HOME UP NEXT