MySQL 8.0.24

What's new in this version:

Audit Log Notes:
- MySQL Enterprise Audit now supports audit log file pruning, for JSON-format log files. See Space Management of Audit Log Files.

Compilation Notes:
- GCC 10 is now a supported compiler for building MySQL on EL7 or EL8. This compiler is available in the devtoolset-10 (EL7) or gcc-toolset-10 (EL8) package. It is also recommended to use GCC 10 when building third-party applications that are based on the libmysqlclient C API library.

Connection Management Notes:
- Previously, if a client did not use the connection to the server within the period specified by the wait_timeout system variable and the server closed the connection, the client received no notification of the reason. Typically, the client would see Lost connection to MySQL server during query (CR_SERVER_LOST) or MySQL server has gone away (CR_SERVER_GONE_ERROR).
- In such cases, the server now writes the reason to the connection before closing it, and client receives a more informative error message, The client was disconnected by the server because of inactivity. See wait_timeout and interactive_timeout for configuring this behavior. (ER_CLIENT_INTERACTION_TIMEOUT).
- The previous behavior still applies for client connections to older servers and connections to the server by older clients

Error Handling:
- Client connection failure messages now include the port number. For example: Can't connect to MySQL server on '127.0.0.1:63333'

Keyring Notes:
- If a keyring component is installed, the new Performance Schema keyring_component_status table provides status information about it. See The keyring_component_status Table.
- Key migration capabilities have been expanded. Previously, key migration occurred only from one keyring plugin to another. The new --keyring-migration-to-component server option enables key migration from a keyring plugin to a keyring component; this facilitates transitioning a MySQL installation from keyring plugins to keyring components. The new mysql_migrate_keyring utility enables key migration from one keyring component to another. See Migrating Keys Between Keyring Keystores. There is no provision for migrating keys from a keyring component to a keyring plugin.
- Existing keyring plugins remain available with no change to user-visible characteristics, but their implementation was revised to use the component infrastructure. This is facilitated using the built-in plugin named daemon_keyring_proxy_plugin that acts as a bridge between the plugin and component service APIs. See The Keyring Proxy Bridge Plugin.

MySQL Keyring previously implemented keystore capabilities using server plugins, but now is transitioning to use the MySQL component infrastructure, beginning with these keyring components:
- component_keyring_file stores keyring data in a file local to the server host. This component is available in MySQL Community Edition and MySQL Enterprise Edition distributions. See Using the component_keyring_file File-Based Keyring Component.
- component_keyring_encrypted_file stores keyring data in an encrypted, password-protected file local to the server host. This component is available in MySQL Enterprise Edition distributions. See Using the component_keyring_encrypted_file Encrypted File-Based Keyring Component.
- The new keyring components have similarities to the existing keyring_file and keyring_encrypted_file plugins, but are configured differently, use distinct on-disk storage formats, and have fewer restrictions on key type and key size.
- Keyring components are not loaded using the --early-plugin-load server option during startup or configured during startup or at runtime using system variables:
- During startup, the server determines which keyring component to load using a manifest file, and the loaded component consults its own configuration file when it initializes. See Keyring Component Installation.
- At runtime, the new ALTER INSTANCE RELOAD KEYRING statement enables reconfiguring an installed keyring component after changes to its configuration file. See ALTER INSTANCE Statement.

Optimizer Notes:
- The MySQL query optimizer can now apply the derived table optimization to correlated scalar subqueries. This is done by applying an extra grouping and then an outer join on the lifted predicate. For example, a query such as SELECT * FROM t1 WHERE (SELECT a FROM t2 WHERE t2.a=t1.a) > 0 can be rewritten as SELECT t1.* FROM t1 LEFT OUTER JOIN (SELECT a, COUNT(*) AS ct FROM t2 GROUP BY a) AS derived ON t1.a = derived.a WHERE derived.a > 0.
- If the subquery already has an explicit grouping, MySQL adds the extra grouping to the end of the existing grouping list
- MySQL performs a cardinality check to ensure that the subquery does not return more than one row, and raises ER_SUBQUERY_NO_1_ROW if it does. The check is performed as part of evaluating any WHERE or JOIN clause in the rewritten query, before evaluating the lifted predicate.
- For more information, see Correlated Subqueries, as well as Derived Tables.

Packaging Notes:
- The bundled libedit library was upgraded to version 20190324-3.1
- Binary packages that include curl rather than linking to the system curl library have been upgraded to use curl 7.74.0

Performance Schema Notes:
Incompatible Change: Instrumentation in the Performance Schema setup_instruments table was revised as follows:
- There are new memory instruments to account for memory allocated to data dictionary infrastructure and objects
- Some instruments were renamed for improved uniformity of instrument naming. Affected instrument names are grouped using a key prefix in the same style as C++ namespaces. For example, error-related instruments use a error:: prefix and partition-related instruments use a Partition:: prefix. The following table displays the affected instruments. In addition, the servers instrument is a duplicate of servers_cache and has been removed. Applications that use the old or removed instrument names should be adjusted to account for this change.
- Several instruments were given a value in the DOCUMENTATION column (it is no longer NULL), improving runtime instrumentation documentation availability.
- Pluggable Authentication
- The new caching_sha2_password_digest_rounds system variable enables configuring the number of hash rounds used by the caching_sha2_password authentication plugin for password storage.

Security Notes:
- For platforms on which OpenSSL libraries are bundled, the linked OpenSSL library for MySQL Server has been updated to version 1.1.1k
- Spatial Data Support
- The new ST_LineInterpolatePoint() and ST_LineInterpolatePoints() functions return a single point or multiple points interpolated between the start point and endpoint of a LineString geometry. The new ST_PointAtDistance() function returns a single point a given distance along a LineString geometry. See Spatial Operator Functions.
- The new ST_Collect() aggregate function takes multiple geometry arguments and produces from them a single geometry collection value. See Spatial Aggregate Functions
- The CAST() and CONVERT() functions have been extended to support casting geometry values from one spatial type to another. See Cast Functions and Operators.
- Functionality Added or Changed
- InnoDB: The AUTOEXTEND_SIZE maximum setting was increased from 64M to 4GB. The AUTOEXTEND_SIZE option, introduced in MySQL 8.0.23, defines the amount by which InnoDB extends the size of a tablespace when it becomes full. The option is supported with the CREATE TABLE, ALTER TABLE, CREATE TABLESPACE, and ALTER TABLESPACE statements. For more information, see Tablespace AUTOEXTEND_SIZE Configuration
- Microsoft Windows: The /RTC1 compiler flag was removed from the debug compiler flags to reduce the time needed to run all tests invoked by the mysql-test-run.pl script when using MSVC on Windows. Initially, this compiler flag was introduced with the CMake program (by default for debug builds) and it generated code to test for stack corruption around function calls and the use of uninitialized variables at runtime. No loss of bug discovery is expected with the removal of the /RTC1 compiler flag. Memory errors, such as stack corruption, are more likely to be found by Address Sanitizer (ASAN) testing and the use of uninitialized variables are detected by compiler warnings.
- Microsoft Windows: The named_pipe_full_access_group system variable now defaults to an empty string (''), making named pipe connections secure. Previously, '*everyone*' was the default value. A valid Windows local group name may be substituted.
- The new clone_donor_timeout_after_network_failure Clone plugin variable defines the amount of time the donor allows for the recipient to reconnect and restart a cloning operation following a network failure. The timeout was previously fixed at 5 minutes. The timeout can now be extended up to 30 minutes to provide more time for network issues to be resolved.
- Client applications and test suite plugins now report utf8mb3 rather than utf8 when writing character set names
- Group Replication’s allowlist of hosts from which an incoming Group Communication System connection can be accepted, can now be updated while Group Replication is still running. You can therefore add new members to a group controlled by an allowlist without needing to stop and restart Group Replication. The allowlist is specified by the group_replication_ip_allowlist system variable on each group member.
- The --skip-slave-start command line parameter is used to prevent the replication I/O thread and replication SQL thread from starting when a replica server restarts. However, using the parameter on the command line or in a my.cnf option file might require login access to the server host. The skip_slave_start system variable is now provided to give access to this feature using MySQL Server’s privilege structure, so that database administrators do not need any privileged access to the operating system. The new global system variable is read-only and can be set using a SET PERSIST_ONLY statement. As a system variable, its value can also be queried from a MySQL client and used by MySQL APIs. The --skip-slave-start command line parameter can still be used as an alternative, and it sets the new global system variable.

Fixed:
- Important Note: When a utf8mb3 collation was specified in a CREATE TABLE statement, SHOW CREATE TABLE, DEFAULT CHARSET, the values of system variables containing character set names, and the binary log all subsequently displayed the character set as utf8 which is becoming a synonym for utf8mb4. Now in such cases, utf8mb3 is shown instead, and CREATE TABLE raises the warning 'collation_name' is a collation of the deprecated character set UTF8MB3. Please consider using UTF8MB4 with an appropriate collation instead
- InnoDB: Stale pages encountered by the buf_page_create() function were freed and then read from disk again without being reinitialized
- InnoDB: C++ enum type values in buffer pool page and buffer pool block data structures in the InnoDB source code were changed from int to uint8_t in MySQL 8.0.23, causing the data to be printed as ascii characters instead of integers in different outputs including messages and INFORMATION_SCHEMA tables.
- The function that populates the INNODB_BUFFER_PAGE_LRU table did not print the IO_PIN state for the IO_FIX field.
- InnoDB: The btr_pcur_t::copy_stored_position function, which copies the position of one index tree persistent cursor to another, performed unnecessary free and malloc calls.
- InnoDB: A function that checks for locks on a table tried to acquire an exclusive lock system (lock_sys) latch, causing long semaphore waits.
- InnoDB: Counting temporary tablespaces as open files caused the innodb_open_files limit to be exceeded, preventing other files from being opened. Temporary tablespaces are now ignored when counting open files.
- InnoDB: The buf_flush_ready_for_flush() function identified a stale page as ready to flush without first checking if the page was dirty or I/O fixed, causing an assertion failure.
- InnoDB: Rollback of a transaction that modified generated columns raised an assertion failure. The failure occurred when attempting to free space occupied by externally stored columns. The update vector containing the externally stored columns did not account for the generated columns.
- InnoDB: When starting the server with innodb_validate_tablespace_paths disabled, user-created undo tablespaces, which are temporarily set to inactive during the initial stages of the startup process, were not reactivated.
- InnoDB: Disabling innodb_extend_and_initialize, which causes InnoDB to use fallocate() when allocating space to tablespace files, caused a performance regression for insert-oriented workloads.
- InnoDB: An unnecessary full flush list scan was removed, improving the speed with which session temporary tablespaces are created. Previously, depending on the size of the buffer pool and the number of dirty pages, creation of session temporary tablespaces could take a long time, affecting write transaction performance.
- InnoDB: A function that checks if a given page type is valid raised an assertion when testing valid but undefined page type for an undo tablespace.
- InnoDB: Sharded read-write lock function instrumentation was improved.
- InnoDB: On Windows, when creating a table with the COMPRESSION option, InnoDB failed to check the error status of a system call before checking the punch hole support flag set by the same system call, which resulted in reading an uninitialized flag.
- InnoDB: Geometry columns created in MySQL 5.6 caused failure when restarting the server after upgrading from MySQL 5.7 to MySQL 8.0 due to a geometry type change introduced in MySQL 5.7.
- InnoDB: During recovery, log records for multiple record group mini transactions were parsed twice. The log record from the first parsing operation is now saved to avoid the second pass, which improves recovery performance.
- Thanks to Zhai Weixiang for the contribution.
- InnoDB: In debug builds, an end range condition check for a secondary index raised an assertion failure, and Valgrind testing uncovered an end range condition check for secondary index on a virtual column that read an uninitialized value.
- InnoDB: With the innodb_log_writer_threads variable disabled, extensive log writing by one thread could block log flushing opportunities for other threads.
- InnoDB: In SHOW ENGINE INNODB STATUS deadlock information, in cases where a single rw-lock reader thread holds a shared latch, the reader thread id was not printed.
- InnoDB: Running concurrent SHOW CREATE TABLE and ALTER TABLE operations on the same table raised an assertion failure. The SHOW CREATE TABLE thread referenced a tablespace object that had been made stale by the ALTER TABLE operation.
- InnoDB: The introduction of sharded rw_lock_stats counters in MySQL 5.7 caused a regression in CPU cache efficiency. To address this issue in MySQL 5.7, the sharding method was changed. For optimal performance, the rw_lock_stats counter is removed in MySQL 8.0.
- InnoDB: On Windows, stalls were caused by concurrent SELECT COUNT(*) queries where the number of parallel read threads exceeded the number of machine cores.
- InnoDB: An IS_STALE column, which indicates whether a buffer pool page is stale, was added to the INFORMATION_SCHEMA.INNODB_BUFFER_PAGE table.
- InnoDB: In debug builds, the log_free_check() function in the redo log code, which ensures that there is available space in the logs when holding latches on dirty pages, now uses a list of mini-transactions opened by the current thread to search for potential constraint violations.
- InnoDB: During a slow shutdown on a system with a 64k InnoDB page size and innodb_max_undo_log_size setting that was less than the initial undo tablespace size, the two undo tablespaces were truncated in an endless loop. Undo tablespace truncation is now restricted to undo tablespaces that are larger than the initial undo tablespace size and the innodb_max_undo_log_size setting.
- The function that retrieves the next redo rollback segment for an undo tablespace was modified to ensure that undo logs are evenly split between two active undo tablespaces when an inactive tablespace is found.
- InnoDB: Starting the server in upgrade mode following an unexpected stoppage while the undo_001 undo tablespace was being truncated caused failure. When upgrade processing was completed and shutdown initiated, the function that determines if undo truncation is required could not find the undo_001 undo tablespace. To address this issue, undo tablespace truncation is no longer performed when starting the server in upgrade mode.
- InnoDB: A delete operation on a parent table that initiated a cascading update on a child table with an indexed virtual column and indexed foreign key constraint column caused a virtual column corruption.
- InnoDB: The open and close sequence for table share instances (m_share objects) and dictionary table instances was modified to prevent accessing old m_share objects that could point to stale dictionary indexes.
- Thanks to Yuxiang Jiang for the contribution.
- InnoDB: An debug assertion failure occurred when issuing a TRUNCATE TABLE operation after a successful server restart following a server initialization failure.
- InnoDB: A fast shutdown (innodb_fast_shutdown=0) raised an assertion failure. The assertion code checks for transactions in the transaction list (mysql_trx_list) before halting purge operations. The check occurred before shutting down the GTID persister background thread, which was still inserting transactions into the transaction list.
- InnoDB: Undo tablespace truncation error handling was improved, and a Windows-specific InnoDB file deletion procedure was made more POSIX-compatible.
- InnoDB: Initializing the server with an with a 4K InnoDB page size caused “key too long” errors to be written to the error log. - InnoDB: Creating an index on virtual columns raised an invalid debug assertion failure. - InnoDB: In debug mode, the buf_pool_validate_instance() function accessed the buf_page_t::io_fix field without properly synchronizing with a thread that was modifying the same field in the buf_page_io_complete() function, causing an assertion failure. In addition to correcting that issue, the buf_page_get_io_fix_unlocked() function was replaced by several specific functions that test the buf_page_t::io_fix field for particular values. A series of other small, related code changes were also implemented.
- InnoDB: The TempTable memory allocator did not track RAM consumption when allocating blocks of memory shared by different queries for a given session, which could result in nonadherence to the temptable_max_ram limit.
- Partitioning: In some cases, invalid PARTITION clauses were not handled correctly in ALTER TABLE statements.
- Replication: Binary log transaction compression could not continue if a row event included a BLOB column containing uncompressable data, and the compressed size of the row event was higher than its uncompressed size. The function now handles the additional post-compression bytes correctly.
- Replication: If all previous binary log files were purged at startup because their retention period had expired, the new binary log file contained an empty Previous_gtids event, which could cause errors in replication. The order of initialization has now been changed so that previous binary log files are only purged after the previous GTID set has been written to the new binary log file that is created at startup.
- Replication: When MySQL Server counted the number of GTIDs in a set, it was possible for the return value to wrap, returning an incorrect result. This could lead to an incorrect decision to use state transfer from the binary log for Group Replication’s distributed recovery, when a remote cloning operation would have been more efficient. The logic has now been corrected.
- Replication: An assertion was raised in debug builds relating to lost GTIDs if binary log files were removed at startup because their retention period had expired.
- Replication: The sql_slave_skip_counter system variable, which is used to make a replica skip a specified number of transactions, ignored transaction payloads that had been compressed using binary log transaction compression (activated using the binlog_transaction_compression system variable). Only events in uncompressed transaction payloads were counted towards the total skipped.
- Replication: A deadlock could occur if the binary log file was rotated while system variables were being updated and read by different clients.
- Replication: The output of a SHOW PROCESSLIST statement for a replica’s SQL thread sometimes showed the last query as currently being applied when the replica was actually caught up. - Microsoft Windows: Running MySQL Server (64-bit) on a Windows system with more than 32 logical processors and setting the VCPU attribute of a resource group to greater than 30 produced an incorrect CPU mask value, which is used to set the thread affinity. Under these conditions, the MSVC compiler reported warnings that the 32-bit shift was converted implicitly to 64-bit in the thread_attrs_api_win.cc file. The conversion resulted in the wrong CPU mask calculation on systems that have more than 32 logical processors. This fix ensures that a 64-bit shift is used when calculating the CPU mask by replacing argument 1 of the shift with 1LL.
- JSON: The IF() function sometimes hit an assertion in debug builds when an error was raised from its first argument; this also could occur under similar circumstances with the additional condition that the function's return type was JSON.
- JSON: A number of JSON functions did not propagate errors correctly, which could lead to assert failures in debug builds.
- JSON: JSON_TABLE() inside triggers was sometimes handled incorrectly when re-used in different sessions. Fixed by ensuring that JSON_TABLE() and its temporary table are processed in the context of the current session.
- JSON: A multi-valued index defined on an expression that cast a column into a typed array was not used for speeding up queries. This was because the server, when substituting an expression with an equivalent indexed generated column, did not attempt to replace a reference to a column with a reference to an equivalent generated column; for multi-valued indexes, it makes sense to replace the column reference with a reference to a generated column backing a multi-valued index on an expression that cast that column into a typed array.
- This fix lifts the restriction that the server attempts to substitute only function expressions and conditional expressions with indexed generated columns, by allowing substitution of column references when they appear in a context where they can make use of a multi-valued index, that is, when they are used as arguments to MEMBER OF(), JSON_CONTAINS(), or JSON_OVERLAPS(). The restriction remains in force for cases in which the column reference is used in a non-array context.
- JSON: The JSON_SEARCH() function interpreted all search string and path values as utf8mb4 strings, regardless of their actual encoding, which could lead to wrong results
- JSON: In some cases, when used in a left join, some MySQL JSON functions caused the optimizer to transform it into an inner join, even though the inner join was not equivalent to the original left join. This was due to the fact that they return a value which is not NULL, even though one of their arguments is NULL, and the optimizer expected them to return NULL on NULL input.
- Functions affected by this issue included JSON_ARRAY(), JSON_OBJECT(), JSON_ARRAY_APPEND(), JSON_ARRAY_INSERT(), JSON_INSERT(), JSON_REPLACE(), and JSON_SET(). See JSON Functions, for more information about these functions
- Community packages for generic Linux were not built with the necessary LDAP/SASL/Kerberos dependencies, and did not bundle the associated required libraries.
- The functions BIT_AND(), BIT_OR(), BIT_XOR(), and JSON_ARRAYAGG() did not always provide proper error handling.
- The server did not always provide proper error messages when IN was incorrectly used with UNION.
- It was possible for casting from DECIMAL to a signed integer type to hit an assertion when the result had more digits than the metadata in Item_typecast_signed indicated it would have. This happened because the decimal value is rounded when converted to an integer, and Item_typecast_signed did not take into account that the rounding might increase the number of digits in what was the integer part of the decimal value, such as when rounding 9.9 up to 10.
- This is fixed by removing the logic that tried to compute a minimal maximum length for the result of the cast, and instead using the default set by the parent class Item_int_func. That default is the maximum width of a 64-bit integer, which should be safe regardless of the input value.
- The name my_row_id was not permitted for invisible columns. This restriction has been lifted.
- On a system with many concurrent connections, execution of grant statements could take excessively long waiting for metadata locks, causing the server to become unresponsive.
- Windows binaries and libraries were not being properly signed.
- Privilege checks for INFORMATION_SCHEMA tables could fail to take the lower_case_table_names value into account.
- LIKE ... ESCAPE, where ESCAPE did not reference a constant value, was not handled correctly within a prepared statement.
- MySQL has traditionally interpreted an empty value in the ESCAPE clause (that is, ESCAPE '') for LIKE as “no escape character”. Problems could arise when either of the first two arguments to LIKE was a string using a multibyte character set, because the empty value in such cases was interpreted as meaning that the backslash () should be used as the escape character, breaking the expected behavior.
- This fix causes LIKE to interpret ESCAPE '' as meaning that there is no escape character regardless of character set, restoring the previous, expected behavior.
- In addition, we now raise an error if the specified escape character cannot be converted to the target character set. This supersedes the original behavior in such cases, which was to fall back silently to using the backslash as the escape character.
- Windows packages were subject to an OpenSSL vulnerability.
- User-defined function arguments containing window functions or subqueries could produce unexpected results.
- Improper handling of temporary tables used for cursors within stored procedures could result in unexpected server behavior.
- Use of the symbol TRUE in the source resulted in a build failure on some platforms. This was replaced by true.
- The privilege check used to determine whether users can see view definitions in the INFORMATION_SCHEMA.VIEWS table worked incorrectly.
- For recursive common table expressions, an assertion could be raised if it became necessary to convert an in-memory temporary table to on-disk.
- A prepared statement employing a user-created function was not handled correctly when the function took no arguments.
- A clone plugin installation failure could cause subsequent installation attempts to fail.
- Some internal functions used with temporal column types did not provide proper handling for YEAR values.
- The internal constants MAX_FLOAT_STR_LENGTH = 12 and MAX_DOUBLE_STR_LENGTH = 22 represent the maximum lengths of strings representing FLOAT and DOUBLE values, respectively. The heuristic employed by the conversion routine my_gcvt for determining whether to use scientific notation sometimes generated strings that were longer than these.
- These long strings caused problems for some string conversion routines, since their actual lengths could exceed the expected maximums. We fix this by explicitly telling my_gcvt the desired length whenever we fetch a FLOAT or DOUBLE in a string context.
- Within triggers, use of RAND() with no arguments could lead to unexpected server behavior.
- A missing tablespace error was reported on the recipient MySQL server instance after a remote cloning operation. The tablespace was not cloned due to the innodb_validate_tablespace_paths variable being disabled on the donor instance, which resulted in the associated tablespace object not being loaded. A check is now performed before a cloning operation to ensure that all tablespace objects are loaded.
- Some query blocks containing large numbers of EXISTS subqueries were not always handled correctly.
- mysqlpump could exit unexpectedly if a SHOW CREATE TABLE statement failed.
- A long running remote cloning operation failed due to a low wait_timeout setting on the donor MySQL Server instance. Donor threads use the MySQL Server wait_timeout setting when listening for Clone protocol commands. To avoid timeout failures on donor instances with a low wait_timeout setting, the Clone idle timeout is now set to the default wait_timeout setting, which is 28800 seconds (8 hours). Clone network read and write timeout values were also increased.
- Replication threads running in the server were visible in the Performance Schema threads table, but failed to appear in the variables_by_thread or status_by_thread tables. Now they appear in all three tables. Thanks to Facebook for the contribution.
- A query string was displayed before it had been rewritten
- For builds compiled using the libedit library, if the mysql client was invoked with the --default-character-set=utf8 option, libedit rejected input of multibyte characters.
- On Windows, large result sets could cause the mysql client to exit unexpectedly.
- Preparing a query expression for repeated execution could raise an assertion if an error occurred during preparation.
- Functional index creation did not handle the column name as not case-sensitive.
- Temporary tables bound to triggers during statement execution could cause an unexpected server exit
- Improved NULL and error handling in calculations involving decimal values
- An assertion was raised if there was an open handler to a table in a schema when the schema was altered to be read only.
- Selecting from the Performance Schema replication_group_members table in some cases raised Error 1267 Illegal mix of collations .... This was due to a change in MySQL 8.0.22 in the handling of comparisons between a column value and a system variable.
- MySQL produced invalid metadata for a number of temporal functions returning integer values. These functions included TO_DAYS(), PERIOD_DIFF(), PERIOD_ADD(), TO_SECONDS(), DAYOFMONTH(), DAYOFYEAR(), HOUR(), and MINUTE(), among others.
- Table subqueries of a natural join which retrieved only invisible columns were not handled correctly.
- For debug builds, using ALTER TABLE to set a column to have a DEFAULT value of TRUE raised an assertion.
- When an error was raised while evaluating a condition that was pushed down to the storage engine using index condition pushdown, the storage engine sometimes ignored the error and returned an error code indicating success, which could lead to assertion failures later.
- Now in such cases, we make sure that the executor detects that an error has been raised, and stop execution at that point.
- For debug builds with binary logging disabled, ALTER TABLE ... MODIFY COLUMN with an invalid DEFAULT value raised an assertion.
- Preparation of an aggregate function sometimes hit an assertion in debug builds when the function took a constant scalar subquery as argument and the scalar subquery raised an error.
- For debug builds, improper character set handling for NULLIF() evaluated in aggregate context raised an assertion.
- A CREATE TABLE statement with an unsupported KEY_BLOCK_SIZE value raised an assertion.
- Upgrading a MySQL instance with a very large number of tables consumed an excessive amount of memory. Memory allocated to analyze data dictionary entities for possible upgrade was not released until all entities were processed.
- ANALYZE TABLE executed on a table concurrently with a long-running query on the same table caused subsequent queries on the table to wait for the long-running query to finish. This wait induced by ANALYZE TABLE is now eliminated, thus allowing the subsequent queries to execute with no wait.
- Statements using a LIKE expression with an ESCAPE clause were not always handled correctly.
- On ARM platforms, an assertion could be raised in utilities used during the build process.
- InnoDB did not always handle some legal names for table partitions correctly.
- With the explicit_defaults_for_timestamp variable disabled, Clone plugin installation failed with PFS table creation error. The variable setting caused TIMESTAMP columns in the Clone Performance Schema tables to be created incorrectly as NOT NULL columns.
- SHOW CREATE VIEW produced invalid syntax for views created with a ROLLUP clause. This issue also affected mysqldump, which uses SHOW CREATE VIEW.
- A failed CREATE TABLE or ALTER TABLE with SECONDARY_ENGINE_ATTRIBUTE could leak memory.
- Connection establishment failure could cause the server to count the number of open connections incorrectly.
- Refactoring work done in MySQL 8.0.19 did not handle left joins correctly on columns using functions such as IFNULL().
- The optimizer could choose to use a Skip Scan even for backward index scans for which it is inapplicable, resulting in unpredictable server behavior.
- UDF function arguments containing window functions were evaluated at prepare time despite the fact that window functions are set up quite late in the prepare process. Now evaluation of these is delayed until execution time, similarly to how this is performed with respect to UDF arguments containing subqueries. 5)
- Creating a table containing a column with a nonconstant default expression caused subsequent ALTER TABLE statements to fail.
- Updating a BLOB-like column with a value from a larger BLOB-like column could cause the updated column to have the wrong size, even zero.
- A race condition could occur if a STOP GROUP_REPLICATION statement was used to stop a group member, while the Performance Schema statistics for Group Replication were being queried by another client. Group Replication now prevents STOP GROUP_REPLICATION statements and Performance Schema queries from running concurrently.
- Improper locking on an internal queue could cause mysqlpump to exit unexpectedly.
- The server did not always prepare correctly a statement using GROUP_CONCAT() on a SELECT with an ORDER BY clause.
- The sys schema create_synonym_db() procedure fail to create INFORMATION_SCHEMA synonyms.
- Errors occurring in window functions were not always correctly propagated, which could lead to assertion failures in debug builds.
- It is now possible to use START REPLICA SQL_THREAD and STOP REPLICA SQL_THREAD statements for the group_replication_applier channel when Group Replication is stopped. This enables an operator to apply any remaining unapplied transactions on a server that left the group, without having to rejoin the server to the group. 7)
- Calling XA COMMIT on a transaction started by another thread could result in Address Sanitizer warnings.
- When the mysql client was used in batch mode, its parser could be confused by USE followed by DROP DATABASE when the USE database name was quoted.
- A change in MySQL 8.0.17 caused comp_err to become much slower. Normal performance has been restored.
- References: This issue is a regression of: 1, - Using CAST() on a DATE or DATETIME value in an INSERT statement raised a warning for "0000-00-00" and "2000-02-31", but not for "2000-01-00" or "2000-00-01". Now a warning is shown in each of these cases also.
- The maximum length of the MASTER_COMPRESSION_ALGORITHMS value for the CHANGE MASTER TO statement was checked incorrectly.
- When casting a dynamic parameter to YEAR (such as in PREPARE s FROM "SELECT CAST(? AS YEAR)"), type propagation was not preformed, causing execution of the prepared statement in which the parameter was used to fail.
- Definitions of some system tables for a MySQL 5.7 instance upgraded to MySQL 8.0 differed from the definitions of the system tables in a new MySQL 8.0 installation.
- Some SHOW statements using subqueries could result in unexpected server behavior.
- A query using GROUP BY column HAVING column_expression IS [NOT] NULL returned correct results, but when WITH ROLLUP was added did not.
- The SHOW ENGINE PERFORMANCE SCHEMA STATUS statement reported incorrect memory usage for the Performance Schema.
- When trying to generate an entity data model using Visual Studio 2019, some tables could not be imported with the entity framework wizard. This was due to a change in MySQL 8.0.21 made to orthogonal data type aggregation, which handles columns from UNION and from functions or operators such as CASE and IF(). This makes it possible to return a value of type ENUM or SET, which did not need to be handled previously in such cases.
- While optimizing the ORDER BY clause of a subquery there was a possibility of cleaning up a subquery tree referenced in the outer SELECT, which could lead to a premature exit.
- A malformed name in the mysql.func system table could cause unexpected server behavior.
- Sessions could disable their own auditing.
- Compiler options for using profile guided optimization with GCC were improved to include -fprofile-partial-training and -fprofile-update=prefer-atomic when appropriate. Thanks to Dmitriy Philimonov for the suggestion. - Starting the server with the performance_schema_max_thread_classes and performance_schema_max_thread_instances system variables set to zero caused MySQL Enterprise Firewall to be unable to create new rules. 4, - A null pointer was incremented during recovery from the redo log, causing a runtime error in an Undefined Behavior Sanitizer (UBSAN) build. 1)
- With the log_slow_extra system variable enabled to add the Errno field to slow query log output, the error number was 0 even for failed statements. - On debug builds, certain conversion operations using the utf32 character set could cause unexpected server behavior.
- SELECT ... FOR UPDATE from a nonexistent Performance Schema table produced ER_TABLEACCESS_DENIED_ERROR rather than ER_NO_SUCH_TABLE. - Mishandling of stored program local variables could lead to unexpected server behavior.
- The Performance Schema metadata_locks table could show incorrect DURATION values, such as when a metadata lock taken for a TRANSACTION duration was later modified to EXPLICIT duration by a RENAME TABLE operation. - The audit_log plugin could fail to store its encryption password if it generated one at startup.
- Uninstalling a plugin could affect subsequent execution of prepared statements.
- Conversion of string-valued user-defined variables or function results to double (for example, using CAST()) did not emit a warning when truncation occurred.
- When a view definition used LIKE with an ESCAPE clause, the contents of the ESCAPE clause were ignored, leading to wrong results.
- It was possible to insert illegal ASCII values (outside 7-bit range) into character columns that used the ascii character set. This is now prohibited.
- To enable use of spaces and other special characters within configuration values, mysql_config_editor now surrounds values it writes to the configuration file with double quote characters, and also escapes double quote characters used within values. - When the aggregate iterator finds no rows, it calls on each item in its SELECT list to inform them of this (for example, so that COUNT(*) can set itself to zero, or SUM(foo) can set itself to NULL). After internal work done in MySQL 8.0.22, it could also inadvertently call hidden items. In some queries with doubly nested subqueries, one such hidden item could become its own parent subquery (and scalar subqueries in MySQL have special legacy handling of this call, for queries which are not ONLY_FULL_GROUP_BY), causing the entire subquery to return NULL when it should not have done so.
- This is fixed by making the call only on visible items, as in MySQL 8.0.21 and earlier
- When interpreting the old-style plan to access paths, cache invalidators for LATERAL were delayed until all outer joins were completed, since outer joins could produce null-complemented rows that should also invalidate caches. Problems arose when an outer join contained a LATERAL, and that LATERAL referred only to tables from within the same outer join; in such cases the invalidator should be applied immediately and not delayed, lest we miss emitted rows, and the cache be incorrectly kept. In particular, this could happen when certain Information Schema tables were on the right side of an outer join, as these are now views defined using LATERAL.
- We fix this by delaying emission of the invalidator until we are inside the same (outer) join nest as the materialization to be invalidated, but no further. This also deals correctly with the case where rows from a table should invalidate two or more separate materializations, where some are within the join and some are higher up
- An optimizer trace printed floating-point numbers with a maximum six characters, which meant that the precision could be very low for many values, given that sign, decimal point, and exponent could use many of these characters. This was especially problematic for large numbers, whose precision could thus be as small as 1, and which could be rounded to values whose absolute value exceeded DBL_MAX and so could be rejected by JSON parsers.
- Now such numbers are always printed in an optimizer trace with a precision of 6
- Filesort was used for a query having an ORDER BY ... DESC clause, even when an index on the descending column was available and used. This happened because an ORDER BY sub-clause was not removed due to matching a field in an equality predicate, even though it should have, so that the optimizer did not match the query with the descending index, leading to suboptimal performance
- The debug server hit an assert when optimizer_search_depth was less than the number of JOIN_TAB structures used for a join
- Following the ALTER TABLE operations EXCHANGE PARTITION, IMPORT TABLESPACE, and IMPORT PARTITION TABLESPACE, serialized digital information reflecting the previous role of the tablespace was left behind. Now in such cases, the old SDI is explicitly removed from both tablespaces involved in the exchange or import of a tablespace
- Type resolution performed by the integer division operator (DIV) yielded a precision of one less than expected in the result.