Documentation Home
MySQL 8.0 Release Notes
Related Documentation
MySQL 8.0 Reference Manual
Download these Release Notes
PDF (US Ltr) - 4.2Mb
PDF (A4) - 4.3Mb
MySQL 8.0 Release Notes  /  Changes in MySQL 8.0.18 (2019-10-14, General Availability)

Changes in MySQL 8.0.18 (2019-10-14, General Availability)

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

Account Management Notes

Compilation Notes

  • Incompatible Change: The my_ulonglong type is no longer used in MySQL source code. Any third-party code that used this type should use the uint64_t C type instead. Also, it is possible that printf() format strings will need adjustment if used to print my_ulonglong variables. (Bug #29453827)

  • For building MySQL 8.0, the minimum required version of Protobuf is now 3.0 rather than 2.5. (Bug #30141272)

  • The minimum version of the Boost library for server builds is now 1.70.0. (Bug #29639344)

  • A DBUG_TRACE macro is available to assist in writing debug code. It is a convenience that replaces pairs of enter/leave macros. For example, instead of writing this: 

    void foo() {
  DBUG_ENTER("foo");
  bar();
  DBUG_VOID_RETURN;
}

    Write this instead: 

    void foo() {
  DBUG_TRACE;
  bar();
}

    (Bug #29589102)

Configuration Notes

  • CMake now enables use of fastcov if it is available. fastcov is faster than lcov or gcov. This requires GCC and gcov versions of 9 or higher. (Bug #30011512)

  • The DISABLE_SHARED CMake option was unused and has been removed. (Bug #29971049, Bug #96027)

  • The CMake code to find Protobuf executables now works on platforms that split these into multiple packages. (Bug #29953773)

  • The new ADD_GDB_INDEX CMake option determines whether to enable generation of a .gdb_index section in binaries, which makes loading them in a debugger faster. The option is disabled by default. It has no effect if a linker other than lld or GNU gold is used. (Bug #29925009, Bug #95857)

  • For the INSTALL_LAYOUT CMake option, the SLES and WIN option values were not used and have been removed. (Bug #29871520, Bug #95654)

  • The max_prepared_stmt_count system variable maximum value has been increased from 1 million (1,048,576) to 4 million (4,194,304). The default value remains unchanged at 16,382. (WL #13342)

  • MySQL 8.0 no longer supports building using wolfSSL. All MySQL builds now use OpenSSL. (WL #13290)

  • The RE2 library is no longer used by MySQL. The library is no longer bundled with source distributions and the WITH_RE2 CMake option is obsolete.

Connection Management Notes

  • MySQL now provides more control over the use of compression to minimize the number of bytes sent over connections to the server. Previously, a given connection was either uncompressed or used the zlib compression algorithm. Now, it is also possible to use the zstd algorithm (zstd 1.3), and to select a compression level for zstd connections. The permitted compression algorithms can be configured on the server side, as well as on the connection-origination side for connections by client programs and by servers participating in master/slave replication or Group Replication. For more information, see Connection Compression Control.

    Connection compression using the zstd algorithm requires that the server be built with zstd library support. The new WITH_ZSTD CMake option indicates whether to use the bundled or system zstd library.

    Legacy compression-control parameters, such as the --compress client option, are deprecated and will be removed in a future MySQL version.

    Thanks to Facebook for the contribution on which some of this work was based. (WL #12039, WL #12475)

Deprecation and Removal Notes

  • Use of the MYSQL_PWD environment variable to specify a MySQL password is considered insecure because its value may be visible to other system users. MYSQL_PWD is now deprecated and will be removed in a future MySQL version. (WL #13449)

  • The relay_log_info_file system variable and --master-info-file option are now deprecated and will be removed in a future MySQL version. These were used to specify the name of the relay log info log and master info log when relay_log_info_repository=FILE and master_info_repository=FILE were set, but those settings have been deprecated. The use of files for the relay log info log and master info log has been superseded by crash-safe slave tables, which are the default in MySQL 8.0. (WL #11031)

  • The slave_rows_search_algorithms system variable is now deprecated and will be removed in a future MySQL version. This variable was used to control how rows were searched for matches when preparing batches of rows for row-based logging and replication. The default setting INDEX_SCAN,HASH_SCAN has been found to be optimal for performance and works correctly in all scenarios. (WL #12892)

  • The log_bin_use_v1_row_events system variable is now deprecated and will be removed in a future MySQL version. When set to ON, the variable made mysqld write the binary log using Version 1 binary log row events, instead of Version 2 binary log row events which are the default from MySQL 5.6. (The default is OFF.) The use of Version 1 binary log row events enabled row-based replication with slaves running MySQL Server 5.5 and earlier, which could not use Version 2 binary log row events. (WL #12926)

  • The WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() function is now deprecated, and the WAIT_FOR_EXECUTED_GTID_SET() function should be used instead. Both functions wait until all of the specified transactions have been applied, or until the optional timeout has elapsed. However, WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() applied to a specific replication channel, and stopped only after the transactions had been applied on that channel, for which the applier had to be running. In contrast, WAIT_FOR_EXECUTED_GTID_SET() stops after the specified transactions have been applied on the server, regardless of how they were applied (on any replication channel or from any user client), and whether or not any replication channels are running. WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() could hang indefinitely if an expected transaction arrived on a different replication channel or from a user client, for example in a failover or manual recovery situation, and no timeout was set. (WL #13178)

Keyring Notes

  • MySQL Enterprise Edition now includes a keyring_hashicorp plugin that uses HashiCorp Vault as a back end for keyring storage. For more information, see The MySQL Keyring. (WL #12522)

Logging Notes

  • Log buffering during server startup was adjusted for less delay in the appearance of output in the error log. (Bug #30019632)

Optimizer Notes

  • Queries involving first match split jump operations were handled wrongly in the iterator executor. They are now rewritten to weedout. (Bug #30220791)

  • Hash joins have been implemented as a way of executing inner equi-joins in MySQL. For example, a query such as this one can be executed as a hash join beginning with this release: 

    SELECT *
    FROM t1
    JOIN t2
        ON t1.c1 = t2.c1;

    Multi-table joins using equi-joins can also take advantage of this optimization.

    A hash join requires no index for execution. In most cases, a hash join is more efficient than the block-nested loop algorithm previously used for equi-joins without indexes.

    By default, beginning with this release, a hash join is used whenever a join includes at least one equi-join condition, and no indexes can be applied to the join condition. (A hash join can still be used where there are indexes applying to single-table predicates only.) This preference can be overridden by setting the hash_join optimizer switch to off, or by using the NO_HASH_JOIN optimizer hint. In addition, you can control the amount of memory used by a hash join by setting join_buffer_size. A join whose memory requirement exceeds this amount is executed on disk; an on-disk hash join uses a number of disk files and may not be executable if this number exceeds open_files_limit.

    A hash join cannot be employed if the join conditions for any pair of joined tables do not include at least one equi-join condition among all join conditions used. A hash join is used for a Cartesian product—that is, a join that specifies no join conditions at all.

    You can see whether hash joins have been used to optimize a query in the output of EXPLAIN FORMAT=TREE or EXPLAIN ANALYZE.

    In addition, inner joins using hash joins can now also take advantage of Batched Key Access (BKA). Outer joins still allocate the entire join buffer.

    For more information, see Hash Join Optimization. (WL #2241, WL #13002)

  • Added EXPLAIN ANALYZE, which provides iterator-based timing, cost, and other information about queries in TREE format. This statement produces output similar to that of EXPLAIN, but with additional information about how optimizer estimates match actual execution. (WL #4168)

  • MySQL now performs injection of casts into queries to avoid certain data type mismatches; that is, the optimizer now adds casting operations in the item tree inside expressions and conditions in which the data type of the argument and the expected data type do not match. This makes the query as executed equivalent to one which is compliant with the SQL standard while maintaining backwards compatibility with previous releases of MySQL.

    Such implicit casts are now performed between temporal types and numeric types by casting both arguments as DOUBLE whenever they are compared using any of the standard numeric comparison operators. They are also now performed for such comparisons between DATE or TIME values and DATETIME values, in which case the arguments are cast as DATETIME.

    For example, a query such as SELECT * FROM t1 JOIN t2 ON t1.int_col = t2.date_col is rewritten and executed as SELECT * FROM t1 JOIN t2 ON CAST(t1.int_col AS DOUBLE) = CAST(t2.date_col AS DOUBLE), and SELECT * FROM t1 JOIN t2 ON t1.time_col = t2.date_col is transformed to SELECT * FROM t1 JOIN t2 ON CAST(t1.time_col AS DATETIME) = CAST(t2.date_col AS DATETIME) prior to execution.

    It is possible to see when casts are injected into a given query by viewing the output of EXPLAIN ANALYZE, EXPLAIN FORMAT=JSON, or EXPLAIN FORMAT=TREE. EXPLAIN can also be used, but in this case it is also necessary to issue SHOW WARNINGS afterwards.

    This change is not expected to cause any difference in query results or performance. (WL #12108)

Packaging Notes

  • The component_test_page_track_component.so test plugin has been moved to -test packages. (Bug #30199634)

  • Binary packages that include curl rather than linking to the system curl library have been upgraded to use curl 7.65.3. (Bug #30015512)

Pluggable Authentication

  • To assist in debugging failed connections for accounts that use an LDAP authentication plugin, the authentication_ldap_simple_log_status and authentication_ldap_sasl_log_status system variables now accept a maximum value of 6 (formerly 5). Setting either variable to 6 causes debugging messages from the LDAP library to be written to the error log for the corresponding plugin. (Bug #29771393)

Security Notes

Spatial Data Support

sys Schema Notes

  • The sys.schema_unused_indexes view now filters out unique indexes. Thanks to Gillian Gunson for the contribution. (Bug #24798995, Bug #83257)

  • The sys.ps_is_consumer_enabled() function now produces an error rather than returning NULL if the argument is an unknown non-NULL consumer name. (Bug #24760317)

  • Previously, sys schema sources were maintained in a separate Git repository. sys schema sources now are included with and maintained within MySQL source distributions (under scripts/sys_schema). As a consequence of this change, to simplify maintenance of sys schema scripts going forward, the acceptable format of statements in the file named by the init_file system variable has been expanded. For details, see the description of that variable in Server System Variables.

    The sys.version view is deprecated and will be removed in a future MySQL version. Affected applications should be adjusted to use an alternative instead. For example, use the VERSION() function to retrieve the MySQL server version. (WL #12673)

Test Suite Notes

  • MySQL tests were updated to use the latest version of googletest. (Bug #30079649)

X Plugin Notes

  • X Protocol did not correctly display large numbers of warning messages that were issued for the same query. (Bug #30055869)

  • When the NO_BACKSLASH_ESCAPES SQL mode was enabled, X Plugin incorrectly reported collections as tables. (Bug #28208285)

Functionality Added or Changed

  • Replication; Group Replication: By default, MySQL replication (including Group Replication) does not carry out privilege checks when transactions that were already accepted by another server are applied on a replication slave or group member. From MySQL 8.0.18, you can create a user account with the appropriate privileges to apply the transactions that are normally replicated on a channel, and specify this as the PRIVILEGE_CHECKS_USER account for the replication applier. MySQL then checks each transaction against the user account's privileges to verify that you have authorized the operation for that channel. The account can also be safely used by an administrator to apply or reapply transactions from mysqlbinlog output, for example to recover from a replication error on the channel. The use of a PRIVILEGE_CHECKS_USER account helps secure a replication channel against the unauthorized or accidental use of privileged or unwanted operations.

    You grant the REPLICATION_APPLIER privilege to enable a user account to appear as the PRIVILEGE_CHECKS_USER for a replication applier thread, and to execute the internal-use BINLOG statements used by mysqlbinlog. After setting up the user account, use the GRANT statement to grant additional privileges to enable the user account to make the database changes that you expect the applier thread to carry out, such as updating specific tables held on the server. These same privileges enable an administrator to use the account if they need to execute any of those transactions manually on the replication channel. If an unexpected operation is attempted for which you did not grant the appropriate privileges, the operation is disallowed and the replication applier thread stops with an error. (WL #12966)

  • Group Replication: For group communication connections, Group Replication now supports the TLSv1.3 protocol, which was supported by MySQL Server from 8.0.16. To use the TLSv1.3 protocol, MySQL Server must be compiled using OpenSSL 1.1.1 or higher. For information on configuring encrypted connections for Group Replication, see Securing Group Communication Connections with Secure Socket Layer (SSL). (WL #12990)

  • Group Replication: A new option OFFLINE_MODE is available for the group_replication_exit_state_action system variable, which specifies how Group Replication behaves when a server instance leaves the group unintentionally, for example after encountering an applier error, or in the case of a loss of majority, or when another member of the group expels it due to a suspicion timing out.

    When OFFLINE_MODE is specified as the exit action, Group Replication switches MySQL to offline mode by setting the system variable offline_mode to ON. When the member is in offline mode, connected client users are disconnected on their next request and connections are no longer accepted, with the exception of client users that have the CONNECTION_ADMIN or SUPER privilege. Group Replication also sets the system variable super_read_only to ON, so clients cannot make any updates, even if they have connected with the SUPER privilege.

    The OFFLINE_MODE exit action prevents updates like the default READ_ONLY exit action does, but also prevents stale reads (with the exception of reads by client users with the stated privileges), and enables proxy tools such as MySQL Router to recognize that the server is unavailable and redirect client connections. It also leaves the instance running so that an administrator can attempt to resolve the issue without shutting down MySQL, unlike the existing alternative ABORT_SERVER exit action, which shuts down the instance. (WL #12895)

  • Group Replication: An internal message service has been added to Group Replication. MySQL modules can use the service to transmit generic messages with an identifying tag to all group members, using Group Replication's existing group communication connections. (WL #12896)

  • When the server is run with --initialize, there is no reason to load non-early plugins. The server now logs a warning and ignores any --plugin-load or --plugin-load-add options given with --initialize. (Bug #29622406)

  • The number of diagnostic messages relating to INFORMATION_SCHEMA upgrade during server startup has been reduced. (Bug #29440725, Bug #94559)

  • Prior to MySQL 8.0, REVOKE produced an error for attempts to revoke an unknown privilege. In MySQL 8.0, an account can possess a privilege that is currently unknown to the server if it is a dynamic account that was granted while the component or plugin that registers the privilege was installed. If that component or plugin is subsequently uninstalled, the privilege becomes unregistered, although accounts that possess the privilege still possess it. Revoking such a privilege cannot be distinguished from revoking a privilege that actually is invalid, so REVOKE no longer produces an error for attempts to revoke an unknown privilege. However, to indicate that the privilege is currently unknown, REVOKE now produces a warning. (Bug #29395197)

  • The new innodb_idle_flush_pct variable permits placing a limit on page flushing during idle periods, which can help extend the life of solid state storage devices. See Limiting Buffer Flushing During Idle Periods.

    Thanks to Facebook for the contribution. (Bug #27147088, Bug #88566, WL #13115)

  • mysqld invoked with the --help option no longer aborts if the secure_file_priv argument does not exist. (Bug #26336130)

  • The Protobuf libraries are now dynamically linked. Their default locations are /usr/lib64/mysql/private/ for RPMs, /usr/lib/mysql/private/ for DEBs, and /lib/private/ for TAR builds. A new INSTALL_PRIV_LIBDIR CMake variable controls the location. (WL #13126)

Bugs Fixed

  • NDB Cluster: A query handled using a pushed condition produced incorrect results when it included an ORDER BY clause. (Bug #29595346)

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

  • NDB Cluster: The NDB transporter layer limits the size of messages to 32768 bytes; send buffers place additional (and stricter) limitations on message size. Whenever a message is appended to a send buffer, page checks are performed to ensure that the message fits in the available space; if not, a new page is used. The current issue arose on account of the fact that no check was performed to make sure that this message could fit in the empty page; when the size of the message exceeded the empty page, this resulted in a buffer overwrite and in the overwriting of the next page in memory. For data nodes the largest message supported by the send buffer (thr_send_page) is 32756 bytes; for API and management nodes, this maximum is 32752 bytes. (Signals sent within an individual data node are not subject to these limitations since no send or transporter buffers are used in this case). Now, when a new page is used, the size of the message is checked against that which is available in a new page.

    As part of the work done to fix the problem just described, three new DUMP commands are added to facilitate related testing and debugging: DUMP 103003 (CmvmiRelayDumpStateOrd) sends a DUMP command using another node; DUMP 103004 (CmvmiDummySignal) and DUMP 103005 (CmvmiSendDummySignal) can be used to send long messages. (Bug #29024275)

  • NDB Cluster: EXPLAIN FORMAT=TREE did not provide proper explanations of conditions and joins pushed down to the NDBCLUSTER storage engine. Issues included the following:

    • Pushed conditions were not shown.

    • The root of a pushed join was not shown.

    • The child of a pushed join did not include any reference to its parent operation.

  • InnoDB: An internal function (btr_push_update_extern_fields()) used to fetch newly added externally stored fields and update them during a pessimistic update or when going back to a previous version of a record was no longer required. Newly added externally stored fields are updated by a different function. Also, the method used to determine the number of externally stored fields was corrected. (Bug #30342846)

  • InnoDB: An DROP UNDO TABLESPACE operation on an undo tablespace with a missing data file caused a segmentation fault. (Bug #30155290)

  • InnoDB: An error in the internal trx_rseg_add_rollback_segments function was corrected. (Bug #30114226, Bug #96372)

  • InnoDB: Problematic assertion code in the Contention-Aware Transaction Scheduling (CATS) code was revised. (Bug #30086559)

  • InnoDB: Arguments passed to a derived class in calls from the ib::fatal and ib::fatal_or_error constructors could be ignored, resulting in invalid error messages. Additionally, in the case of a fatal error, the ib::fatal_or_error destructor could cause a server exit before printing a message. (Bug #30071930)

  • InnoDB: It was possible for a corrupted table to be removed from the table cache before the reference count for the table reached zero. (Bug #30065947, Bug #96224)

  • InnoDB: A code path for the internal row_update_inplace_for_intrinsic() function did not include a required mini-transaction (mtr) commit, causing a debug assertion failure. (Bug #30065518)

  • InnoDB: The internal fsp_srv_undo_tablespace_fixup() function did not take an undo::ddl_mutex lock when called during startup, which could lead to an assertion failure under certain circumstances. (Bug #30029433, Bug #30461911, Bug #97356)

  • InnoDB: Inspection of rename_tablespace_name() function showed that if old_shard->get_space_by_id(space_id) did not find the tablespace ID, it would return without calling old_shard->mutex_release(). (Bug #30027771)

  • InnoDB: A tablespace with “FTS” in its name was incorrectly determined to be the tablespace of a full-text index table and not registered with the data dictionary during upgrade, causing the upgrade operation to fail. (Bug #29992589)

  • InnoDB: The ibuf_merge_or_delete_for_page() function, responsible for merging and deleting pages in the change buffer, is no longer called for undo tablespaces and temporary tablespaces. The change buffer does not contain entries for those tablespace types. (Bug #29960394, Bug #95989)

  • InnoDB: Some combinations of buffer pool size variables (--innodb-buffer-pool-instances, --innodb-buffer-pool-size, and --innodb-buffer-pool-chunk-size) lead to a chunk size that is 0, 1, or a value that is not a multiple of the page size, and so on, causing errors during buffer pool creation and sizing. (Bug #29951982)

  • InnoDB: A server exit while an undo tablespace was being truncated caused the following error when a clone operation was rolled forward after restarting the server: [ERROR] [MY-011825] [InnoDB] [FATAL] Clone File Roll Forward: Invalid File State: 0. (Bug #29949917)

  • InnoDB: An ALTER TABLE ... DISCARD TABLESPACE operation caused a hang condition. (Bug #29942556, Bug #30324703)

  • InnoDB: Cloning operations failed with the following error after an archive thread failure: ERROR 3862 (HY000): Clone Donor Error: 1317 : Query execution was interrupted. (Bug #29930839)

  • InnoDB: A clone related regression caused a minor drop in performance for index and non-index update operations. (Bug #29925409)

  • InnoDB: InnoDB now ignores hidden directories and files during the tablespace discovery scan that occurs at startup. Hidden directories and files include those beginning with "." and hidden and system directories and files on Windows that are identified by attributes. (Bug #29900671, Bug #95071, Bug #30068072)

  • InnoDB: To improve deadlock detection, the task of detecting a deadlock cycle among data locks was moved from the transaction thread to a dedicated background thread. (Bug #29882690)

  • InnoDB: Updating the mysql.gtid_executed table during mysqld initialization caused the following warning to be printed to the error log: [Warning] [MY-010015] [Repl] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened. The update and associated warning no longer occur. (Bug #29871809)

  • InnoDB: The LATEST DETECTED DEADLOCK section in InnoDB Standard Monitor output (also printed by SHOW ENGINE INNODB STATUS) was extended to include additional information about transactions that participate in a deadlock cycle. (Bug #29871641)

  • InnoDB: An incorrect argument was used to compare serialized dictionary information (SDI) input and output values when checking the size of the buffer used to store SDI. (Bug #29871525, Bug #95606)

  • InnoDB: An undo tablespace file was overwritten during a cloning operation when undo tablespaces files with the same name were copied from different directories on the donor to the same directory on the recipient. A cloning operation now reports an error if duplicate undo tablespace names are encountered. When data is cloned to the recipient, undo tablespace files are cloned to the directory defined by the innodb_undo_directory variable. Because the files are cloned to the same directory, duplicate undo tablespace file names are not permitted. (Bug #29837617)

  • InnoDB: A cloning operation generated a large number of redo log files when cloning from a MySQL server instance with a small redo log file size and a large number of transactions. The large number of redo log files sometimes caused startup to hang or assert. Otherwise, startup was permitted proceed without cleaning up the excessive number of redo log files. (Bug #29837490)

  • InnoDB: During recovery, missing table errors that occur when applying redo logs to encrypted tables could be ignored, permitting startup to proceed. Startup should be halted in this case. (Bug #29820184, Bug #95183)

  • InnoDB: The wrong redo log file size was printed to the server error log at startup. (Bug #29818711)

  • InnoDB: A restriction that prevented reuse of lock objects (lock_t structs) in the lock queue when waiting record lock requests were present was removed. (Bug #29814308)

  • InnoDB: When converting a long partitioned table name to a file name, the buffer that holds the file name did not have enough space, causing an assertion failure. (Bug #29813582)

  • InnoDB: Some transaction lock structure fields (trx->lock) were not properly mutex protected. (Bug #29809137)

  • InnoDB: An empty undo segment update during recovery raised an assertion. (Bug #29802703)

  • InnoDB: A cloning operation failed when attempting to drop data on the recipient if the recipient data included a table with a full-text index. (Bug #29796507)

  • InnoDB: After a file-per-table tablespace was discarded, an error was reported when the old table was renamed and a new table was created with the same name. The error was due to stale file path information. (Bug #29793800)

  • InnoDB: A test case that attempts to open a file in read-only mode while the server is in a disk-full state caused a debug assertion failure. The assertion was removed to permit the server to retry opening the file, and to report an error if unsuccessful after a number of attempts. (Bug #29692250, Bug #95128)

  • InnoDB: Foreign-key-related tables constructed during a RENAME TABLE operation contained the old table name. (Bug #29686796)

  • InnoDB: The server passed a NULL value for a column with a non-zero data length. (Bug #29654465)

  • InnoDB: Importing a partitioned table from a MySQL 8.0.13 instance (or earlier) to a MySQL 8.0.14, 8.0.15, or 8.0.16 instance failed with a “tablespace is missing” error for source and target instances defined with lower_case_table_names=1. The tablespace file and the metadata file used by the import operation could not be found due to a file name case mismatch. (Bug #29627690, Bug #94850)

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

  • InnoDB: The read set (TABLE::read_set) was not set properly for handler method calls in QUICK_SKIP_SCAN_SELECT::get_next(), causing an assertion failure. (Bug #29602393)

  • InnoDB: An exclusive backup lock is now used to block tablespace truncate operations during master key rotation. Previously, metadata locks on undo tablespace names were used to synchronize the operations. This patch also addresses a deadlock that could occur between master key rotation and drop undo tablespace operations. (Bug #29549938, Bug #30461225, Bug #97352)

  • InnoDB: An unnecessary next key lock was taken when performing a SELECT...FOR [SHARE|UPDATE] query with a WHERE condition that specifies a range, causing one too many rows to be locked. The most common occurrences of this issue have been addressed so that only rows and gaps that intersect the searched range are locked. (Bug #29508068)

  • InnoDB: Adding a virtual column in the first position together with a normal column raised an assertion failure. (Bug #29501324)

  • InnoDB: The shutdown process did not wait for InnoDB background threads to exit, which could cause shutdown to stall, waiting for background threads to remove transactions from the MySQL transaction list. A check now occurs to ensure that InnoDB background threads have exited properly. Also, an intermediate shutdown state was added to improve shutdown timing for the InnoDB master thread. (Bug #29417503)

  • InnoDB: A memory leak occurred during TempTable storage engine operation due a failure to deallocate that last block of allocated memory, which TempTable holds in thread-local storage until thread exit. (Bug #29300927)

  • InnoDB: Throughput stalled under a heavy workload with a small innodb_io_capacity_max setting, a single page cleaner thread, and multiple buffer pool instances. (Bug #29029294)

  • InnoDB: A long running ALTER TABLE ... ADD INDEX operation with concurrent inserts caused semaphore waits. Thanks to Satya Bodapati for the patch. (Bug #29008298)

  • InnoDB: The INFORMATION_SCHEMA.INNODB_COLUMNS table did not display partitioned table columns after upgrading from MySQL 5.7 to MySQL 8.0. For partitioned tables created on the MySQL 8.0 release, INFORMATION_SCHEMA.INNODB_COLUMNS only displayed columns for the first table partition. (Bug #28869903, Bug #93033)

  • InnoDB: The internal rtr_page_split_and_insert() function is called recursively. An inner call to the function released an object still being used by an outer call to the same function, causing an assertion failure. (Bug #28569379)

  • InnoDB: Under specific circumstances, setting the innodb_limit_optimistic_insert_debug variable to 2 raised a debug assertion when it should have reported an error. (Bug #28552330, Bug #92187)

  • InnoDB: A deadlock was possible when a transaction tries to upgrade a record lock to a next key lock. (Bug #23755664, Bug #82127)

  • InnoDB: The INFORMATION_SCHEMA.INNODB_METRICS lock_deadlocks counter did not count all deadlocks. Thanks to Laurynas Biveinis for the contribution. (Bug #21278148, Bug #77399)

  • InnoDB: An error reported during a read operation did not identify the name of the file that was read. (Bug #21120885, Bug #76020)

  • Replication: If the group_replication_set_communication_protocol() function was used to set a communication protocol version that some group members did not support, the protocol change procedure was not stopped correctly. The issue has now been fixed. (Bug #30209596)

  • Replication: The session value of the default_table_encryption system variable is replicated, so that replication slaves preserve the correct encryption setting for databases and tablespaces. For a replication channel where the table_encryption_privilege_check system variable is set to ON, the TABLE_ENCRYPTION_ADMIN privilege is required to apply events where the session value of default_table_encryption is changed. If this privilege had not been granted on the replication slave, replication stopped with an error in some situations where the required encryption setting for the event was actually the same as the slave's own default encryption setting, so the action ought to have worked. It was also possible for a statement with a different encryption setting from the slave to succeed when it ought not to have worked. The behaviors have now been corrected so that a replication slave without the TABLE_ENCRYPTION_ADMIN privilege is permitted to apply events that match its own default encryption setting, and is not requested to set the encryption setting unnecessarily, but is still subject to appropriate privilege checks if the event requires a different encryption setting. (Bug #29818605)

  • Replication: The timeout in seconds specified by the group_replication_unreachable_majority_timeout system variable was only checked every two seconds. The timeout is now checked every second so that odd-numbered values are respected. (Bug #29762005)

  • Replication: A deadlock involving three threads could occur if a START SLAVE statement was issued to start the SQL thread on a slave while the SQL thread was still in the process of being stopped, and a request for the slave status was made at the same time. The issue has now been fixed by releasing a lock earlier while the SQL thread is being stopped. (Bug #29697588, Bug #95115)

  • Replication: A locking issue in the WAIT_FOR_EXECUTED_GTID_SET() function could cause the server to hang in certain circumstances. The issue has now been corrected. (Bug #29550513)

  • Replication: A deadlock could occur if the value of the binlog_encryption system variable was changed while a START SLAVE statement was being executed. (Bug #29515210)

  • Replication: The heartbeat interval for a replication slave, which is controlled by the MASTER_HEARTBEAT_PERIOD option of the CHANGE MASTER TO statement, can be specified with a resolution in milliseconds. Previously, the master's binary log dump thread used a granularity of seconds to calculate whether a heartbeat signal should be sent to the slave, causing excessive heartbeat activity in the case of multiple skipped events. To remove this issue, all heartbeat-related calculations by the master and slave are now carried out using a granularity of nanoseconds for precision. Thanks to Facebook for the contribution. (Bug #29363787, Bug #94356)

  • Replication: Creation of a table with functional index creates a hidden generated column on the table, but this column did not always appear in the same position in the table, which meant that later adding a column (or columns) to the table might leave the hidden column in a different position as compared to an otherwise identical table already having the additional column or columns in a single CREATE TABLE statement. For example, this difference could be evident between two tables t1 and t2, with t1 created and then altered by the two statements CREATE TABLE t (a INT, INDEX ((a+1))) and ALTER TABLE t ADD COLUMN b INT, and t2 created using CREATE TABLE t2 (a INT, b INT, INDEX ((a+1))), even though SHOW CREATE TABLE t1 and SHOW CREATE TABLE t2 produced identical results (other than for the names of the tables).

    The issue just described could become problematic due to the fact that the internal definitions for the tables as described by Table_map_log_events in the binary log would differ. This meant that, if such a table was created using CREATE TABLE followed by ALTER TABLE on the master, and then a slave was deployed using mysqldump, the slave's version of the table would be created using a single CREATE TABLE statement, and subsequent replication of row events would then fail with an error due to mismatching types.

    This issue is fixed by forcing all hidden generated columns always to be located at the end of the list of columns, with multiple generated columns sorted by column name. If a new functional index part is added to the table, the new hidden column is inserted according to this rule. In addition, if the user creates a new column that is not a generated column, the column is always added before the first hidden column.

    Note

    The structure of tables affected by this change is not changed automatically during upgrade; this must done explicitly by executing ALTER TABLE.

    (Bug #29317684)

  • Replication: If a RESET MASTER statement was stopped during its execution, the binary log was not available for writes afterwards. (Bug #29125121)

  • Replication: On a multi-threaded slave with GTIDs in use and MASTER_AUTO_POSITION set to ON, following an unexpected halt the slave would attempt relay log recovery, which failed if relay logs had been lost, preventing replication from starting. However, this step was unnecessary as GTID auto-positioning can be used to restore any missing transactions. In a recovery situation, the slave now checks first whether MASTER_AUTO_POSITION is set to ON, and if it is, omits the step of calculating the transactions that should be skipped or not skipped, so that the old relay logs are not needed and recovery can proceed without them. (Bug #28830834, Bug #92882)

  • Group Replication: If the TCP connections used by Group Replication time out due to a lengthy network error, the group communication engine (XCom) cannot re-establish its local connection, requiring a restart of Group Replication on the instance (see Bug #25656508). Previously, attempting to stop Group Replication in this situation caused XCom to hang, preventing the restart. This issue has now been fixed so that XCom terminates correctly and Group Replication can be restarted to re-establish the local connection. (Bug #30132500)

    References: See also: Bug #22158368.

  • Group Replication: When the ANSI_QUOTES SQL mode was enabled, Group Replication returned an error when checking for the presence of MySQL Server's clone plugin to perform remote cloning operations for distributed recovery. The issue has now been fixed. (Bug #30099796)

  • Group Replication: default_table_encryption could be changed while Group Replication was running by issuing SET PERSIST, even though this variable should never be settable insuch cases. (Bug #30031228, Bug #96158)

  • Group Replication: If group_replication_local_address was changed for a member which then rejoined the group, copies of the old local address were retained in some locations by the Group Communication System (GCS). To fix this, we now fetch the local address when needed, and no longer obtain it from the cache. (Bug #29910699)

  • Group Replication: When a remote cloning operation was used to provide transactions to a joining member and the joining member was stopped during the operation, it did not shut down cleanly. (Bug #29902389)

  • Group Replication: The input channel introduced in this release uses a shared memory queue instead of a TCP socket for communication between the Group Communication System (GCS) component of Group Replication and the local group communication engine (XCom) instance. This input channel could not be established on SELinux installations, which meant members upgraded to MySQL 8.0.14 or later were unable to rejoin the group. When Group Replication was started, the XCom instance temporarily opened a port from the ephemeral port range to allow GCS to establish a connection for the input channel, but on SELinux the mysqld process did not have permission to connect to this port. A workaround was to amend the SELinux policy to allow MySQL to connect to any port, but this reduced security. This issue is now fixed; XCom and GCS no longer use an ephemeral port to establish a connection for the input channel, but instead use the Group Replication communication port set by group_replication_local_address. This action must be permitted by SELinux (see Frequently Asked Questions). (Bug #29742219, Bug #30087757)

  • Group Replication: Server certificates whose Common Name value used a wildcard were incorrectly rejected. (Bug #29683275, Bug #95068)

  • Group Replication: It was possible for the Group Communication System (GCS) to deliver messages from a member after STOP GROUP_REPLICATION had been issued and the member's status was OFFLINE, resulting in an error. GCS now verifies that the member belongs to a group before delivering any such messages. (Bug #29620900)

  • Group Replication: Some threads that executed transient or minor tasks, such as the delayed plugin initialization thread, were not visible in the Performance Schema threads table. (Bug #28930537, Bug #93212)

  • Group Replication: The implementation for the process of a member leaving the group due to an error has been standardized across components. This ensures that the member carries out exactly the same actions and issues the same error messages consistently, regardless of the original reason for leaving the group. (Bug #28866495, Bug #93027)

  • For XA COMMIT statements, invocation order of the plugins involved in statement execution was nondeterministic, which could lead to replication problems. Thanks to Dennis Gao for contributing a fix. (Bug #31082237, Bug #99051)

  • The keyring_aws plugin was not included in Commercial Docker RPM packages. (Bug #30199423)

  • When generating C source from SQL scripts, Some utf8-encoded characters were split across lines. Thanks to Przemysław Skibiński for the patch. (Bug #30152555, Bug #96449)

  • The ARRAY reserved word was listed as unreserved in the INFORMATION_SCHEMA.KEYWORDS table. (Bug #30134275, Bug #96416)

  • Some statements containing || produced a parse error even with the PIPES_AS_CONCAT SQL mode enabled. (Bug #30131161, Bug #96405)

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

  • LOAD DATA statements incorrectly ignored the NO_AUTO_VALUE_ON_ZERO SQL mode if a SET clause was present. (Bug #30126375)

  • Automatic upgrades failed with a server exit if the thread_pool plugin was enabled. (Bug #30121742)

  • When determining whether to recalculate a materialized derived table for each execution, the uncacheability of the parent query block was used instead of the rematerialize flag on the table (currently only true for JSON_TABLE()). This could cause unneeded rematerializations, especially when making queries against non-merged views, leading to reduced performance. (Bug #30110851)

  • With an IGNORE clause, LOAD DATA should skip rows that produced a CHECK constraint violation and continue with the following rows, but it stopped with an error. (Bug #30084966, Bug #96296)

  • With sql_require_primary_key enabled, clone plugin initialization failed because it created two dynamic Performance Schema tables, which do not support indexes or primary keys. The effect of sql_require_primary_key is now limited to storage engines that can participate in replication (currently all storage engines except the Performance Schema) (Bug #30083300, Bug #96281)

  • Protobuf compilation failed on macOS. (Bug #30079536, Bug #96263)

  • For automatic upgrades, the audit_log plugin was not reloaded, causing auditing to start in legacy mode. (Bug #30068110)

  • In order to remove duplicate rows, the weedout optimization needs a unique identifier for each row, which is provided by the storage engine by calling handler::position(), but this function was not always called at the correct time, or was sometimes called when not needed. Issues regarding how and when to place such calls were the source of many bugs in optimizations. This fix moves the responsibility of calling handler::position() to the iterators, whose default implementations usually handle this task adequately on their own. (Bug #30060691)

    References: See also: Bug #29693294, Bug #30049217, Bug #30153695.

  • The server could exit due to mishandling a COM_PROCESS_INFO command. (Bug #30032302)

  • Warnings are normally generated when deprecated system variables are assigned a value, but this did not occur when persisted system variables were processed during server startup. (Bug #30030648)

  • With bind_address set to a value containing multiple addresses, setting host_cache_size=0 caused a server exit at client connect time. (Bug #30018958)

  • On Windows, Protobuf compilation failed for the Ninja build type. (Bug #30018894)

  • SHOW PROCESSLIST output could include statements that had completed and were no longer in process. (Bug #29999818)

  • A mysqldump error-message buffer was too small, potentially leading to message truncation. (Bug #29999782, Bug #96074)

  • Last used auto-increment values instead of “next to be used” auto-increment values were cached while importing tables from MySQL 5.7 to MySQL 8.0 during an in-place upgrade, which resulted in any tables read from the table cache after upgrade having incorrect auto-increment values. (Bug #29996434)

  • When executing a prepared statement that used constant folding, it was possible to register a location for rollback which was not allocated on the MEMROOT, but rather on the stack, and so was no longer in scope. (Bug #29990693)

    References: See also: Bug #29939331.

  • A warning about ZEROFILL being deprecated was produced for CREATE TABLE ... AS and CREATE TABLE ... LIKE statements that created tables that contained a YEAR column. This could be confusing because the ZEROFILL attribute may only have been added implicitly to the YEAR column. To avoid confusion, the warning is no longer raised for such statements. (Bug #29961060)

  • A query using bitwise operators, such as in WHERE text_col < (int_col & int_col) AND int_col = -1, failed to return any rows as expected. (Bug #29957969)

  • Malformed resource group names in optimizer hints could lead to unexpected server behavior. (Bug #29955732)

  • EXPLAIN, when using FORMAT=TREE, did not show the same costs as with FORMAT=JSON. In particular, when using FORMAT=TREE, the cost calculated took into account eval_cost for joins, but not for base tables. (Bug #29953579)

  • For Solaris, mysqld.cc contained a prototype for memcntl() that is no longer needed. The prototype has been removed. (Bug #29953495, Bug #95971)

  • For Solaris, -DWITH_SSL=system did not work when compiling with GCC. (Bug #29953460, Bug #95970)

  • MySQL builds configured with -DWITHOUT_SERVER=1 failed. (Bug #29948728, Bug #95740)

  • The internal method Field_tiny::pack() did not always perform bounds checking as expected. (Bug #29948029)

    References: See also: Bug #31591391.

  • Improper handling of plugin unloading could cause a server exit. (Bug #29941948)

  • The internal MEM_ROOT class did not handle all out-of-memory errors correctly. (Bug #29940846)

  • JSON_SCHEMA_VALIDATION_REPORT() did not distinguish between a JSON document that did not validate according to a JSON schema and a JSON document which was too deeply nested, which resulted in wrong behavior in some cases. (Bug #29940833)

  • Use of the <=> operator could yield incorrect results for comparisons involving very large constants. (Bug #29939331, Bug #95908)

  • For the keyring_aws plugin, some valid region values for the keyring_aws_region system variable were rejected. (Bug #29933758)

  • For debug builds, an assertion could be raised during UNION queries when computing the combined data type of a GEOMETRY column and SELECT * FROM (SELECT NULL). (Bug #29916900, Bug #95827)

  • For columns defined with the binary character set, SHOW CREATE TABLE could generate CREATE TABLE statements that produced a syntax error when executed. (Bug #29909573, Bug #95801)

  • Data dictionary APIs were added for fetching table names in a schema that use a specific storage engine, and for fetching table names in a schema that are created and hidden by the storage engine. The former is required by NDB, and the latter is required for DROP DATABASE operations. (Bug #29906844, Bug #95792)

  • mysqldump leaked memory when run with the --order-by-primary option. (Bug #29906736)

  • For queries involving functional indexes, EXPLAIN FORMAT=TREE printed the hidden column name instead of the indexed expression. (Bug #29904996)

  • For debug builds, CREATE TABLE ... IGNORE SELECT ... statements did not properly clean up the table state when the last row to be inserted was skipped due to a failed CHECK constraint. This could cause the next statement using the table to raise an assertion. (Bug #29903865)

  • MySQL did not handle execution of a recursive common table expression (CTE) correctly when the termination condition of the recursive query for this CTE had an IN predicate using another recursive CTE. (Bug #29899614)

  • Deserialization of serialized dictionary information (SDI) failed for a table with partitions residing in different tablespace files. (Bug #29898965)

  • For authentication using an LDAP authentication plugin, if the user DN portion was empty and group mapping was configured, authentication assigned an incorrect user DN and skipped the user search. (Bug #29897624)

  • Constraints defined without a name could in some cases cause a server exit. (Bug #29892876)

  • An in-place upgrade from MySQL 5.7 to MySQL 8.0 failed due a missing NDB tablespace. (Bug #29889869, Bug #30113440)

  • mysqlpump produced an error when run against a server older than MySQL 5.7. (Bug #29889253)

  • When Boost was downloaded, CMake configuration logic for determining the size of the downloaded file was incorrect, and could remove that file after a successful download operation. (Bug #29881279)

  • A possible integer overflow due to unsigned integer type casting could lead to later buffer overflow due to arbitrary size memory allocation. (Bug #29878914)

  • When the client character set was other than latin1, the server converted the string representation of a DECIMAL value from latin1 to the client character set. This conversion was not necessary, since all supported client character sets encode numbers in the same way as latin1, and so is no longer performed. (Bug #29875672)

  • The vio_description() debugging function was called in nondebug builds. (Bug #29871361)

  • The fix for a previous issue in MySQL 8.0.3 changed a test for whether an expression over constant DATE values could be cached from allowing any expressions except global variables to a blanket denial of all functions, regardless of whether they were over constants or not, which significantly impacted performance of related queries in which the optimizer needed to perform conversion of a string to a DATE value. This test has been reverted to its original form. (Bug #29871018)

    References: This issue is a regression of: Bug #85471, Bug #28576018.

  • The INFORMATION_SCHEMA can fetch dynamic table statistics from storage engines, but this did not work for partitioned tables. (Bug #29870919, Bug #95641)

  • Retrying a failed access-control statement could permit another thread to acquire a lock on the access-control cache during a window when metadata locks where released and reacquired, resulting in a deadlock. The locks are now not released during the retry operation. (Bug #29870899, Bug #95612)

  • An assertion could be raised if a user without the proper privilege attempted to enable the offline_mode system variable. (Bug #29849046)

  • Fedora packaging configuration put debug information for mysql_config_editor in the wrong package. (Bug #29841342)

  • Attempted use of a freed object during MeCab plugin initialization caused a segmentation fault. (Bug #29832534)

  • The function used to generate entropy for random passwords could sometimes not provide much entropy. (Bug #29808492)

  • With super_read_only enabled, the server could process DROP TABLESPACE improperly. (Bug #29802833)

  • The server did not handle a query with a left join containing a materialized semijoin correctly. (Bug #29800741)

  • For MySQL installed using RPM packages, an initialization script that tested server connectivity misbehaved if the client account authenticated using an LDAP authentication plugin. (Bug #29786782)

  • Improper locking during storage engine initialization could cause a server exit. (Bug #29782379)

  • On a GTID-enabled server, concurrent execution of DROP USER and a prepared statement that accessed a view could deadlock. (Bug #29772622)

  • When performing EXPLAIN FORMAT=JSON on a query of the form SELECT WHERE NOT EXISTS (SELECT FROM (derived_table) WHERE false_condition) involving an antijoin transformation, the subquery was eliminated but its own subqueries were moved up instead of being eliminated along with it. (Bug #29759277)

    References: See also: Bug #30017509.

  • An interrupted tablespace encryption operation caused a discrepancy between data dictionary and storage engine metadata, resulting in an assertion failure on a subsequent attempt to access the tablespace. (Bug #29756808)

  • Simultaneous execution of the event scheduler and DROP EVENT could result in lock acquisition hanging until lock wait timeout. (Bug #29742901, Bug #95223)

  • CHECK constraints were not enforced when a column took its default value from an expression. (Bug #29706689, Bug #95192)

  • When performing two sorts on the same table with no temporary table, both sorts tried to use the same buffer, resulting in a read out of bounds. This could occur when the same query used both DISTINCT and ORDER BY. (Bug #29699759)

  • When performing a weedout involving a sorted table, sorting was not done by row IDs. (Bug #29693294)

  • VS2019 produced compilation errors with debug compilation selected due to use of the /ZI flag. Now /Z7 is used instead. (Bug #29691691, Bug #95125)

  • In source distributions, these changes were made in relation to the DBUG package, to clean up old and unmaintained code in the dbug directory:

    • Moved dbug.cc to the mysys directory, removed the dbug library.

    • Removed unused functions in dbug.cc.

    • Removed the DBUG_LEAVE macro; no longer needed.

    • Wrapped the body of the DBUG_LOG macro in if _db_enabled_(), to avoid formatting of strings that likely will not be printed anyway.

    • Removed the dbug directory.

    (Bug #29680868, Bug #95082)

  • While allocating the reference item array, the count for any window functions was not taken into consideration. As a result, when expressions having window functions were split, the extra space needed to store the new item references was not properly allocated. (Bug #29672621)

  • Setting the collation of a user variable did not work correctly in all cases. (Bug #29665165)

  • Processing of WHERE clauses in SHOW statements was not performed consistently. (Bug #29664758)

  • If clauses to drop and add constraints were specified within the same ALTER TABLE statement, they were executed in incorrect order. (Bug #29652464)

  • EXPLAIN now shows when a result is being sorted by row ID. (Bug #29634196)

  • Unnecessary materialization is no longer performed in either of the following cases:

    • When performing a sort at the end of a join, such as for grouping, and the sorting does not make use of row IDs.

    • When materializing a derived table which is not to be read from more than once.

    (Bug #29634179)

  • CAST(arg AS FLOAT) did not returned the expected out-of-range error when arg was too small to be represented as a FLOAT value. (Bug #29621333)

  • Internal conversion of FLOAT values sometimes occurred at the wrong time, which could lead to excess precision in results. Consider the table created and populated as shown here: 

    CREATE TABLE t(f FLOAT);
INSERT INTO t VALUES (2.3);

    Prior to the fix, the query SELECT f, IF(f > 0, f, 0) FROM t against this table returned (2.3, 2.299999952316284) instead of (2.3, 2.3) as expected. (Bug #29621062)

  • log0meb.cc failed to compile with some build options. (Bug #29616525)

  • The client library could dereference a null pointer while fetching result set metadata from the server. (Bug #29597896, Bug #30689251)

  • A runtime error could occur for interval value checks when summing date and interval values. (Bug #29587536)

  • In builds with Undefined Behavior Sanitizer enabled, multiplication with -9223372036854775808 could produce warnings and incorrect results. (Bug #29581610)

  • During startup, the server attempted to write operations to the binary log that should not have been logged. (Bug #29557747, Bug #94835)

  • A statement of the form CREATE VIEW v1 AS SELECT * FROM table WHERE (constant IN (SELECT constant) IS UNKNOWN) led to an assertion. (Bug #29525304)

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

  • On EL6, if a FIPS-enabled OpenSSL library was not available, attempting to enable FIPS mode could cause a server malfunction. (Bug #29519794)

  • SET PERSIST_ONLY can be used to persist some system variables that SET PERSIST cannot (due to the way variable settings occur). If such a variable is found in mysqld-auto.cnf at startup, the server now issues a warning and ignores the setting. (Bug #29511118)

  • The server did not properly aggregate a partial revoke and a schema-level privilege in some cases. (Bug #29484519)

  • For debug builds, ENUM or SET columns defined with a DEFAULT clause raised an assertion. (Bug #29480711)

  • MySQL Installer did not install OpenSSL DLL dependencies if the Development component was not selected. (Bug #29423421, Bug #94168, Bug #30199579, Bug #96573)

  • In READ UNCOMMITTED isolation level, a segmentation fault occurred under heavy load from memcached clients. An externally stored BLOB column that was being updated by one transaction was read by another transaction as having a NULL value and a non-zero data length. (Bug #29396364, Bug #93961)

  • On systems with working IPv6 address resolution, IPv6 socket creation failure at connect time resulted in a memory leak. (Bug #29374606, Bug #94384)

  • In replication scenarios, if multiple clients concurrently executed XA COMMIT or XA ROLLBACK statements that used the same XID value, replication inconsistency could occur. (Bug #29293279, Bug #94130)

  • Arguments for the TIMESTAMPADD() function could be reversed for prepared statements. (Bug #29268394)

  • The DEFAULT ROLE option for CREATE USER statements was not written to the binary log. (Bug #28948915, Bug #93252)

  • Starting the server from the command line with invalid memcached plugin variable settings caused the server to exit. (Bug #28575863)

  • The SET clause for LOAD DATA did not work to set GEOMETRY NOT NULL columns. (Bug #28460369, Bug #91893)

  • On Windows 8 and higher, the keyring_aws plugin was not able to communicate with Amazon KMS servers. (Bug #28377961)

  • INFORMATION_SCHEMA tables and SHOW COLUMNS could produce incorrect view column types when a query on the view had multiple query blocks combined with the UNION operator. (Bug #28278220, Bug #91486)

  • On Debian, long InnoDB recovery times at startup could cause systemd service startup failure. The default systemd service timeout is now disabled (consistent with RHEL) to prevent this from happening. (Bug #28246585, Bug #91423)

  • With the thread_pool plugin enabled, the sys.processlist and sys.session views displayed a thread name rather than the actual user name. (Bug #25906021, Bug #85976)

  • The delete_latency column in the sys.schema_index_statistics view incorrectly referred to the SUM_TIMER_INSERT column of the Performance Schema table_io_waits_summary_by_index_usage table rather than the SUM_TIMER_DELETE column. (Bug #25521928)

  • In output from the sys.diagnostics() procedure, the latency column for the user_summary_by_file_io_type view was incorrectly displayed in raw picoseconds rather than as a formatted value. (Bug #25287996)

  • MySQL Enterprise Encryption functions could apply Diffie-Hellman (DH) methods to non-DH keys, resulting in unpredictable results or server exit. (Bug #22839007)

  • Password masking was incomplete for SHOW PROCESSLIST and some INFORMATION_SCHEMA and Performance Schema tables. (Bug #20712046)

  • With strict SQL mode enabled, the STR_TO_DATE() function did not properly handle values with time parts only. Thanks to Daniel Black for the contribution. (Bug #18090591, Bug #71386)

  • A query using GREATEST() in the WHERE clause could, in certain cases, fail to return a row where one was expected or raise a spurious error. (Bug #96012, Bug #29963278)

  • Explicitly setting sort_buffer_size to its maximum value or close to it caused some queries to fail with an out of memory error. (Bug #95969, Bug #29952775)

    References: See also: Bug #22594514.

  • Late NULL filtering, to avoid index lookups if the lookup key contains at least one NULL, was not performed for backwards index scans, although it was for forward index scans. (Bug #95967, Bug #29954680)

  • Using a function such as IFNULL() or ABS() in a functional index led to the error Value is out of range for functional index... when an UNSIGNED column used as an argument to such a function contained a value exceeding that of the corresponding signed integer type. (Bug #95881, Bug #29934661)

  • The resolution procedure for the IFNULL() function differed from that for all other functions derived from CASE operations, including COALESCE(), which caused incorrect length information to be generated for certain numeric expressions. (Bug #94614, Bug #29463760)

  • Queries using UNION ALL ... LIMIT 1 evaluated an excessive number of rows as shown by Handler_read_key and Handler_read_next. (Bug #79340, Bug #22292995)

    References: See also: Bug #79040, Bug #22158368, Bug #92994, Bug #28866942.

  • The -DWITH_EXAMPLE_STORAGE_ENGINE=1 CMake option was ignored but should not have been. If -DWITH_EXAMPLE_STORAGE_ENGINE=0 is given, the EXAMPLE storage engine is built as a plugin. (Bug #70859, Bug #17772560, Bug #30133062)

    References: See also: Bug #18324650.


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