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.32 (2023-01-17, General Availability)

Changes in MySQL 8.0.32 (2023-01-17, General Availability)

Authentication Notes

  • The server could return LDAP_OPERATIONS_ERROR for LDAP authentication failures, rather than only for actual LDAP server errors such as when an AD domain is not accessible. Now, the server returns LDAP_AUTHENTICATION_ERROR, a MySQL-specific error code, to indicate authentication errors. (Bug #100333, Bug #31680279)

C API Notes

  • The sha256_password_auth_client_nonblocking() function always returned an error, even when the public key was available. (See the MySQL Server Doxygen documentation, available at https://dev.mysql.com/doc/index-other.html.) Our thanks to Facebook for the several fixes in this patch. (Bug #34556764)

Compilation Notes

  • Microsoft Windows: The authentication_ldap_sasl server plugin is no longer built for Windows as only the client is supported for SASL-based LDAP authentication. (Bug #34448155)

  • On Windows, compiling MySQL server using VS 2022 would emit an error about two projects named "parser-t" if tests and the NDB storage engine were enabled. The tests were renamed to avoid conflict on case-insensitive operating systems. (Bug #34790413)

  • On MacOS, silenced deprecation warnings generated by Xcode 14; this includes suggestions to use snprintf(3) instead of sprintf(3), and warnings about possible loss of precision from 64 to 32 bit integers. (Bug #34776172)

  • Removed the boost library usage from the plugins. (Bug #34694419)

  • Removed all 3rd party files named 'Makefile' as they were not used. (Bug #34648199)

  • Added clang 15 support. (Bug #34638573)

  • Located and removed unused code; located it using fastcov. (Bug #34583577)

  • Improved code related to building the ndbcluster plugin by fixing warnings generated with 'gcc 11.2.0 RelWithDebInfo on Ubuntu 22.04' and 'gcc 8.3.1 on el6'. (Bug #34384889)

  • Now use full file paths for the Bison and Flex source files to help simplify debugging and gcov reports. (Bug #109022, Bug #34776151)

  • Building MySQL would fail if the building user lacked access to the mysqld temporary directory. Now --no-defaults is used when creating the INFO_BIN file. (Bug #108947, Bug #34756282)

Deprecation and Removal Notes

  • Use of the dollar sign ($) as the first character of an unquoted identifier is now deprecated, raises a warning (ER_WARN_DEPRECATED_SYNTAX_NO_REPLACEMENT), and is subject to removal in a future release.

    This affects statements using such an identifier for the name of any database, table, view, column, stored program, or alias. Identifiers beginning with a dollar sign are still permitted only when they are quoted—that is, delimited by single or double quote marks (' or "), or by backtick characters (`), depending on the server SQL mode. Example: 

    mysql> TABLE $t;  # Unquoted, produces warning
+------+
| a    |
+------+
|    1 |
|    2 |
+------+
2 rows in set, 1 warning (0.00 sec)

mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
  Level: Warning
   Code: 1681
Message: '$ as the first character of an unquoted identifier' is deprecated and
will be removed in a future release. 
1 row in set (0.00 sec)

mysql> TABLE `$t`;  # Quoted, no warning
+------+
| a    |
+------+
|    1 |
|    2 |
+------+
2 rows in set (0.00 sec)

    User variables are not affected by this change. For example, the statement SELECT 1 INTO @$x does not produce a warning.

    See Schema Object Names, for more information. (Bug #34785775, WL #15422)

    References: See also: Bug #34684193.

  • The CLIENT_NO_SCHEMA flag is deprecated. Client programs that specify CLIENT_NO_SCHEMA as the client_flag argument to mysql_real_connect() can now omit the flag and the db argument to have the connection set the database value to the current (or default) database. The libmysqlclient library now prints a warning on standard error when mysql_real_connect() is called with CLIENT_NO_SCHEMA. In addition, the server adds a deprecation warning for every non-prepared query executed, if the connection has CLIENT_NO_SCHEMA. (WL #13128)

  • Previously, legacy compression-control parameters were deprecated and replaced with new configuration parameters for greater control over the use of compression in connections to the server. The new and deprecated parameters are:

    The deprecated parameters will be removed in a future MySQL version.

    Now, the following client programs print a deprecation warning to standard error when a client user invokes one of the programs with --compress (or -C, if applicable): mysqlpump, mysqlcheck, mysql, mysqladmin, mysqlbinlog, mysqldump, mysqlimport, mysqlshow, mysqlslap, mysql_upgrade, and mysqltest.

    The mysqlbackup --compress option has different capabilities and is not deprecated. (WL #13292)

Generated Invisible Primary Keys (GIPKs)

  • Replication: It is now possible to cause a replica to add a generated invisible primary key to any InnoDB table that otherwise, as replicated, has no primary key. This is implemented by adding GENERATE as a possible value for the CHANGE REPLICATION SOURCE TO statement's REQUIRE_TABLE_PRIMARY_KEY_CHECK option.

    REQUIRE_TABLE_PRIMARY_KEY_CHECK = GENERATE can be used on a per-channel basis. Suppose the replica is configured with two replication channels, named ch1 and ch2, and you execute the statements shown here: 

    STOP REPLICA;

SET @@sql_require_primary_key = ON;

CHANGE REPLICA SOURCE TO 
  REQUIRE_TABLE_PRIMARY_KEY_CHECK = GENERATE
  FOR CHANNEL ch1;

START REPLICA;

    The effect of these statements is that the replica now adds an invisible primary key for tables whose creation is replicated by channel ch1, but does not do so for any keyless table that is created in the context of ch2.

    A replica ignores any setting for sql_generate_invisible_primary_key that has been made on the source, and this variable is not replicated. (This behavior is unchanged from previous releases.)

    REQUIRE_TABLE_PRIMARY_KEY_CHECK = GENERATE is not compatible with MySQL Group Replication, where ON, OFF, and STREAM are the only supported values for this option.

    See CHANGE REPLICATION SOURCE TO Statement, and Generated Invisible Primary Keys, for further information. (WL #15419)

Keyring Notes

  • Host names of endpoints specified in component_keyring_oci configuration files, and obtained from the Oracle Cloud Infrastructure Console or by querying the Oracle Cloud Infrastructure API, now can retain the https:// prefix that previously had to be removed when generating a MySQL configuration for the Oracle Cloud Infrastructure Vault keyring component. (Bug #34636297)

Pluggable Authentication

  • On Windows, the client-side Kerberos authentication plugin now supports GSSAPI through the MIT Kerberos library. It is possible to choose between SSPI and GSSAPI at runtime using a new plugin option supported by the authentication_kerberos_client authentication plugin on Windows. Client users invoke mysql or mysqldump with the --plugin-authentication-kerberos-client-mode command-line option to set the mode to GSSAPI. The default mode of the authentication_kerberos_client plugin is SSPI, previously the only authentication method on Windows.

    For more information, see Connection Commands for Windows Clients in GSSAPI Mode. (WL #15336)

Spatial Data Support

  • The MySQL ST_Transform() function now supports all Cartesian projections, with the exceptions of EPSG 1042 (Krovak Modified), EPSG 1043 (Krovak Modified (North Orientated)), EPSG 9816 (Tunisia Mining Grid), and EPSG 9826 (Lambert Conic Conformal (West Orientated)). (Bug #27272733, Bug #34495023, WL #15164)

SQL Syntax Notes

  • Important Change: Previously, MySQL supported the use of “full” as the name of a table, column, view, stored procedure, or stored function, as well as for the alias of a table, view, or column. Beginning with this release, using “full” (regardless of letter case) in this fashion as an unquoted identifier is now deprecated, and raises a warning. This is to align more closely with the SQL standard, in which FULL is reserved as a keyword.

    For example, the following CREATE TABLE and DROP TABLE statements now raise warnings, as shown here: 

    mysql> CREATE TABLE full (c1 INT, c2 INT);
Query OK, 0 rows affected, 1 warning (0.03 sec)

mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
  Level: Warning
   Code: 4119
Message: Using FULL as unquoted identifier is deprecated, please use quotes or
rename the identifier. 
1 row in set (0.00 sec)

mysql> DROP TABLE full;
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
  Level: Warning
   Code: 4119
Message: Using FULL as unquoted identifier is deprecated, please use quotes or
rename the identifier. 
1 row in set (0.00 sec)

    To execute the statements without the warnings, encase the table name in each of them with backtick characters (`), like this: 

    mysql> CREATE TABLE `full` (c1 INT, c2 INT);
Query OK, 0 rows affected (0.03 sec)

mysql> DROP TABLE `full`;
Query OK, 0 rows affected (0.02 sec)

    The use of FULL in the right hand side of a value assignment is not affected by this change. For example, the SET statement shown here remains valid: 

    mysql> SHOW VARIABLES LIKE '%metadata%';
+---------------------------------------+---------+
| Variable_name                         | Value   |
+---------------------------------------+---------+
| binlog_row_metadata                   | MINIMAL |
| innodb_stats_on_metadata              | OFF     |
| performance_schema_max_metadata_locks | -1      |
| resultset_metadata                    | FULL    |
+---------------------------------------+---------+
4 rows in set (0.00 sec)

mysql> SET @@global.binlog_row_metadata=FULL;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW VARIABLES LIKE '%metadata%';
+---------------------------------------+-------+
| Variable_name                         | Value |
+---------------------------------------+-------+
| binlog_row_metadata                   | FULL  |
| innodb_stats_on_metadata              | OFF   |
| performance_schema_max_metadata_locks | -1    |
| resultset_metadata                    | FULL  |
+---------------------------------------+-------+
4 rows in set (0.00 sec)

    For more information, see Keywords and Reserved Words. (WL #15241)

  • It is now possible to set the default format for the output of any EXPLAIN statement which obtains a query execution plan, and which has no FORMAT option, using the explain_format system variable added in this release. Like the FORMAT option, this variable can take any of the values TRADITIONAL, JSON, or TREE. DEFAULT is also supported as a synonym for TRADITIONAL. (DEFAULT is not supported with the FORMAT option for EXPLAIN.) Suppose the value of explain_format is TREE; in this case, the output from any such EXPLAIN statement uses the tree-based format, as though FORMAT=TREE had been specified as part of the EXPLAIN statement.

    Any value set for explain_format is overridden by a FORMAT option. This means that, if explain_format is set to TREE, supplying FORMAT=JSON when invoking EXPLAIN causes the value of explain_format to be ignored, and the result is displayed using the JSON format.

    explain_format also affects the behavior of EXPLAIN ANALYZE; since this statement supports only the TREE format, if the value of explain_format is not TREE, this means that any EXPLAIN ANALYZE statement that does not specify the TREE format explicitly raises the error This version of MySQL doesn't yet support 'EXPLAIN ANALYZE with format format'.

    The new system variable has both global and session scope, can be persisted, and can be set from the command line (as --explain-format) or in a my.cnf option file.

    See the description of explain_format. See also Obtaining Execution Plan Information, and Obtaining Information with EXPLAIN ANALYZE, for further information and examples. (WL #15040)

    References: See also: Bug #33629360.

Thread Pool Notes

  • Whenever a connection was terminated due to inactivity, the thread pool plugin printed only a generic message about connections timing out; this often made analysis of such timeouts more difficult than necessary. A new INFO_LEVEL message makes it clear that a connection has been terminated due to inactivity in the thread pool, as well as which timeout value was used to make this determination. (Bug #34767607)

  • Two columns added to the Performance Schema tp_thread_state table in this release make it possible to identify a thread's type, and to map threads in this table to those in the Performance Schema threads table. The type of thread is now shown in the tp_thread_state table's TP_THREAD_TYPE column, and the thread's unique ID in the THREAD_ID column. For more information, see The tp_thread_state Table. (Bug #34020058)

Functionality Added or Changed

  • Important Change: For platforms on which OpenSSL libraries are bundled, the linked OpenSSL library for MySQL Server has been updated to version 1.1.1s. Issues fixed in OpenSSL version 1.1.1s are described at https://www.openssl.org/news/cl111.txt. (Bug #34828308)

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

  • The internal resource-group enhancement added in MySQL 8.0.31 is refactored, but it continues to support the Resource_group_supported status variable. (Bug #34702833, Bug #34699751)

    References: Reverted patches: Bug #34264356.

Bugs Fixed

  • Important Change: The implementation of the max_join_size system variable, although documented as a maximum number of rows or disk seeks, did not check the number of rows or disk seeks directly, but instead treated max_join_size as the maximum estimated cost to permit. While cost and row count are correlated, they are not the same, and this could lead to unexpected results when some large queries were allowed to proceed.

    In this release, we change how max_join_size is used, so that it now actually limits the maximum number of row accesses in base tables. If the estimate indicates that a greater number of rows must be read from the base tables, an error is raised. This makes the actual behavior better reflect what is documented. (Bug #83885, Bug #25118903)

  • InnoDB: Undetectable problems after upgrade from 8.0.28, crash and corruption.

    Any new row inserted after upgrade will have all columns added with ALGORITHM=INSTANT materialized and have version=0.

    In the new implementation, a column added with ALGORITHM=INSTANT will fail if the maximum possible size of a row exceeds the row size limit. So new rows with materialized ALGORITHM=INSTANT columns will always be within row size limit. (Bug #34558510)

  • InnoDB: No more garbled UTF characters in SHOW ENGINE INNODB STATUS (Bug #34486877, Bug #108111)

  • InnoDB: Alter handler adjusted so that adding more than 1024 columns with ALGORITHM=INSTANT no longer causes a crash. (Bug #34378513, Bug #107854)

  • InnoDB: After a column added with ALGORITHM=INSTANT, an online rebuild DDL no longer crashes. (Bug #33788578, Bug #106279)

  • InnoDB: Several adaptive hash index (AHI) code optimizations and improvements were implemented, addressing various issues including potential race conditions. (Bug #33601434)

  • Replication: When SOURCE_HEARTBEAT_PERIOD was set to a very small value (such as 1 microsecond) on the server using CHANGE REPLICATION SOURCE TO, and the mysqlbinlog client program was started with --read-from-remote-server and --stop-never=1, it was possible for the binary log dump thread to send an EOF packet to the client before all events had been sent. (Bug #34860923)

  • Replication: Removed an assert from sql/rpl_group_replication.cc which triggered a false error in testing. (Bug #34619134)

  • Replication: After MySQL was started with --server-id=0, trying to change the server ID by using SET PERSIST server_id=N (where N is an integer greater than zero) and restarting the server had the following results:

    To fix this problem, we now ensure that such checks use the value of the server variable rather than the value passed to the startup option. (Bug #34412816)

  • Replication: When replicating compressed binary log events generated by the NDB binary log injector, relay log positions were not updated in the multithreaded applier, thus causing replication to hang. (Bug #33889030)

    References: See also: Bug #33784241.

  • Replication: Issuing STOP REPLICA SQL_THREAD while the SQL thread was handling a transaction caused replication to stop immediately, instead of waiting 60 seconds for the event group to complete before shutting down the SQL thread as expected.

    The root cause of this issue was due to the internal variable storing the last event start time not being reset after the SQL thread was restarted.

    We fix this by resetting the variable holding the last event start time whenever the SQL thread is started. (Bug #33646899)

  • Replication: While their wording might imply otherwise, the log messages Setting super_read_only=ON (ER_GRP_RPL_SUPER_READ_ON) and Setting super_read_only=OFF (ER_GRP_RPL_SUPER_READ_OFF) were written only after the operations were attempted, and not beforehand, or while the operations were ongoing. This sometimes led to confusion when setting the variable was rejected, and this was logged prior to the set attempt itself being logged. To keep this from happening, these messages are now logged just prior to attempting the operation. (Bug #108843, Bug #34728079)

  • Replication: The relay_log_space_limit system variable is a 64-bit value, but its valid maximum was specified internally as that of a 32-bit value. (Bug #106323, Bug #33799840)

  • Replication: Eliminated an unnecessary update of the gtid_executed table which was performed when rotating the binary logs. (Bug #106116, Bug #33759477)

  • Group Replication: The WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE column of the MySQL Performance Schema's replication_group_communication_information table reflects the runtime value of a Paxos Single Leader setup in a group, letting users know what the value of group_replication_paxos_single_leader must be on joining members.

    A group that was bootstrapped with single-leader enabled but with its protocol version downgraded to one that did not support it reported WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE equal to 0, as expected, but attempting to join an instance to the group using group_replication_paxos_single_leader = 0 was not possible.

    To solve this problem, we change the behaviour and make the value of group_replication_paxos_single_leader consistent with the communication version that the group is running. Since this variable was introduced in MySQL 8.0.27, it is not known or used in any previous version, and so we now enforce the following rules:

    • When a node tries to join a group that is running MySQL 8.0.26 or earlier and we are version 8.0.27 or later, we reject the attempt with an error stating that group_replication_paxos_single_leader must be OFF before joining the group

    • When we try to use group_replication_set_communication_protocol() to set a version less than 8.0.27 and we are of version 8.0.27 or later, we reject the function call if group_replication_paxos_single_leader is not OFF.

    In addition, we also change the value checked to determine whether changing the group leader is allowed after running group_replication_set_communication_protocol(). Previously, this was the runtime value of group_replication_paxos_single_leader, which takes effect only after a group reboot. Instead, when we run group_replication_set_communication_protocol(), we now use the value shown by the replication_group_communication_information table's WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE column, described previously. (Bug #34555045, Bug #34828311)

  • Group Replication: In a 3 node cluster, all nodes were killed due to running out of memory. Subsequently, after all nodes were restarted successfully, attempting to bring the cluster back online caused the node that had been the primary to hang.

    For more information, see Rebooting a Cluster from a Major Outage. (Bug #108339, Bug #34564856)

  • Group Replication: When a group was run with group_replication_consistency = AFTER and a secondary failed due to external conditions such as an unstable network, the secondary could sometimes encounter the error Transaction 'GTID' does not exist on Group Replication consistency manager while receiving remote transaction prepare.

    The root cause of this issue was that the primary might log out of order the View_change_log_event with which the secondary rejoined; when the secondary used the primary as the group donor, this could cause the secondary to catch up with the group improperly and, eventually, generate incorrect GTIDs for the group transactions. The group replication primary ensures that the View_change_log_event is logged after all preceding transactions, but there was a window during which transactions ordered after the View_change_log_event on the group global order could be logged before the event.

    To solve this issue, we now make sure that transactions ordered before a view are always logged before the View_change_log_event, and that transactions ordered after a view are always logged after this event. This is now done by the binary log ticket manager, which guarantees the order in which transactions in the binary log group commit are committed. (Bug #104980, Bug #33405699)

    References: See also: Bug #34746357.

  • Microsoft Windows: When compiling MySQL on Windows platforms, the CMake -DWITH_WIN_JEMALLOC option was not always handled correctly. (Bug #108341, Bug #34698376)

  • JSON: While saving the result of JSON_ARRAYAGG() or JSON_OBJECTAGG() in a column, the data type information was lost due to the result being an item of type SUM_FUNC_ITEM. To fix this, we remove the type check and this way retain the original type information. (Bug #108326, Bug #34548259)

  • Some remote connections to the server were not handled correctly. This issue arose as the result of a previous fix for an issue with require_secure_transport. (Bug #34857411)

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

  • Some query plans were not stable due to nondeterministic sorting of Key_use_array in sql_optimizer.cc; now we sort it with std::stable_sort() instead of std::sort(). (Bug #34823952)

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

  • Binary packages that include OpenLDAP rather than linking to the system OpenLDAP library were upgraded to use version 2.5.13. (Bug #34815046)

  • In some cases, an unexpected packet sent by the server to a MySQL client program during authentication could result in an infinite loop. (Bug #34805922)

  • GIS data was not always handled correctly in windowing functions. (Bug #34778646)

  • A thread remained bound to the CPU of a dropped resource group even after it was assigned to the user default resource group (USR_default). USR_default has 0 CPU priority and no CPU affinity, so with this fix, the thread now is able to run any CPU with USR_default. (Bug #34748973)

  • With JSON logging enabled, calling the audit_log_rotate() function did not rotate the file as expected. A rotated file name consists of the timestamp from the last event logged into the file. When the file is empty, last timestamp is the same as the timestamp in the already created file. To fix this issue, the function now uses the current time to name the file if the file is empty. (Bug #34733508)

  • Some queries having multiple lateral derived tables did not produce the expected result. (Bug #34716246)

  • The bundled zlib library has been upgraded to zlib 1.2.13; zlib 1.2.13 is now the minimum zlib version supported. (Bug #34711762, Bug #34711758)

  • Certain INTERSECT queries were not handled correctly. (Bug #34642435)

  • Using the MAX_EXECUTION_TIME optimizer hint with a value greater than the stated maximum kept an upgrade to MySQL 8.0.30 from completing; this caused the server to report a warning which was interpreted by the upgrade process as an unrecoverable error. (Bug #34607401)

  • In certain cases, evaluation of window functions was not performed correctly. (Bug #34572136)

    References: This issue is a regression of: Bug #32644631, Bug #32802301.

  • Some CTEs were not processed correctly. (Bug #34572040, Bug #34634469)

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

  • Values returned from functions or operators that convert a value to FLOAT (CAST(... AS FLOAT), CONVERT(..., FLOAT), JSON_VALUE(... RETURNING FLOAT)) may have extra precision in their internal representation, since they are stored in double precision internally. This sometimes caused unexpected results when checking such values for equality, such as SELECT DISTINCT returning duplicates and comparison operators incorrectly reporting two equal values as unequal.

    We fix this problem by stripping off the extra double precision from the values before returning them, and by making any conversion from float to string in these conversion operators use float format instead of double format. (Bug #34554755)

  • Removed an assertion in query_expression::assert_not_fully_clean(). (Bug #34526104)

  • Upgrading from MySQL 5.7 to MySQL 8.0 with a very large number of tables in a single database caused the server to consume excessive memory. It was found that, during the process of checking whether tables could be upgraded, we fetched all the data dictionary Table objects upfront, processing each and fetching its name, then performed CHECK TABLE ... FOR UPGRADE on the list. Fetching all objects beforehand was not necessary in this case, and contributed greatly to memory consumption.

    To correct this problem, we now fetch one Table object at a time in such cases, performing any required checks, fetching its name, and releasing the object, before proceeding with the next one. (Bug #34526001)

  • When creating natural join columns, a hidden column added as part of a materialized derived table is used in constructing the join condition, which is later used to check whether the join eligible for pushdown to derived tables. The current issue arose when this column was not retrieved from the derived table due to it being hidden; this occurred even when the condition pushdown optimization was not enabled. We solve this problem by rejecting all hidden columns added internally, and not merely for hidden columns added for functional indexes. (Bug #34523627)

  • Types were not derived consistently from user variables. This could be seen, for example, by executing the following statements repeatedly: 

    CREATE TABLE t AS SELECT @max_error_count UNION SELECT 'a';

SHOW CREATE TABLE t;

    In this particular case, the output of the SHOW CREATE TABLE statement showed `@max_error_count` text the first time, and `@max_error_count` mediumblob in successive iterations. (The second is correct.) (Bug #34523475)

  • Following work done in MySQL 8.0.23 to improve host resolution for user accounts, the time needed for CREATE USER to complete increased significantly, particularly when running many such statements in close succession.

    Prior to upgrading to this release, you can work around this issue when issuing many such statements in succession by preceding them with a single CREATE USER 'fakeuser' ACCOUNT LOCK (you can use any user name that does not conflict with existing ones for this). When finished, you can (and should) clean up by issuing the following statements: 

    DROP USER 'fakeuser';
FLUSH PRIVILEGES;

    For more information, see Access Control, Stage 1: Connection Verification. (Bug #34449016)

  • The data_masking server-side plugin could emit a runtime error and halt unexpectedly. (Bug #34445632)

  • Stack overruns could be erroneously reported when using the thread pool under heavy load. The race condition causing this in the thread pool has been avoided with an additional thread group ID check. (Bug #34414959)

  • Some multiply nested queries were not performed correctly. (Bug #34377854)

  • When merging a derived table, a nested join condition is added to the derived table and the underlying tables are added to this join nest. In addition, the join condition is associated with the derived table.

    Evaluation for range access is skipped if the table is an inner table of an outer join or if the table is an inner table and the join is not a semijoin. For a derived table, the underlying base table was treated as being of the latter kind, range analysis was skipped, and the range access method was thus unavailable.

    To fix this problem, we now evaluate for range access when the embedding table is a derived table, and ensure that the join condition associated with the derived table is used for the range optimization. (Bug #34347116)

  • A LOAD DATA INFILE statement issued with a subquery could cause the server to return an incorrect warning (Subquery returns more than 1 row). (Bug #34336033)

  • Improved handling of resource allocation for internal temporary tables. (Bug #34174001)

  • A specific column added after a drop using the INSTANT algorithm could cause a data error and a server exit. (Bug #34122122)

  • A query such as SELECT 1 AS one FROM t WHERE 1=(SELECT 1 UNION SELECT 2) is transformed to this: 

    SELECT 1 AS one 
FROM t 
JOIN ( SELECT 1 AS col1 UNION SELECT 2) derived
WHERE 1 = derived.col1;

    The optimizer in this case pushed down 1 = derived.col1 into the union, removing the contribution from SELECT 2, which led to an erroneous result. We now no longer push the condition down in such cases. (Bug #33910786)

  • Some parenthesized query expressions with either or both of ORDER BY and LIMIT were not always handled correctly. (Bug #33725530)

  • Reimplemented retention of item trees having multiple references, by using a reference count in every Item object. Also removed old code no longer needed due to this change. (Bug #33725415)

  • An assert occurred in InnoDB during upgrade of the data dictionary when the definition of the innodb_ddl_log table changed, even when such changes were effectively null operations, such as updating utf8 and utf8_bin in table and column definitions to utf8mb3 and utf8mb3_bin, respectively. (Bug #33688509)

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

  • Data and GTIDs backed up by mysqldump were inconsistent when the options --single-transaction and --set-gtid-purged=ON were both used. This was because, between the start of the transaction by mysqldump and the fetching of GTID_EXECUTED, GTIDs on the server could have increased already. With this fix, a FLUSH TABLES WITH READ LOCK is performed before fetching GTID_EXECUTED, to ensure that its value is consistent with the snapshot taken by mysqldump.

    Our thanks to Marcelo Altmann for the contribution.

    Limitation: This fix adds a requirement for the RELOAD privilege when using --single-transaction to execute FLUSH TABLES WITH READ LOCK; the MySQL team is investigating a solution. (Bug #33630199, Bug #105761)

  • SET PERSIST accepted dot-separated names of variables registered by components as well as MyISAM multiple key cache variables, but RESET PERSIST rejected the same names with a syntax error. To fix this discrepancy, we add support in this to RESET PERSIST for variable names containing a dot character (.). (Bug #33417357)

  • Some grouped queries were not always handled correctly. (Bug #33294005, Bug #33349994)

  • When multifactor authentication used the auth_socket authentication plugin for the first factor, the server executed the wrong code during the second-factor authentication workflow and returned an error message. The second factor could be any authentication plugin. (Bug #33192223)

  • Use of a wild card as a column identifier in an INSERT statement was allowed by the parser even though the syntax is not supported, which led to an assert in debug builds and a silent rejection of the statement in release builds. This construction has been removed as a possibility from the grammar, and is now handled strictly as a syntax error. (Bug #33142665)

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

  • In prepared statements, some types of subqueries could cause a server exit. (Bug #33100586)

  • Some floating-point literals were not always handled correctly. (Bug #32824429)

  • A DELETE statement with a table alias could result in an intermittent server exit. (Bug #32762229)

  • Moved INFO_SRC and INFO_BIN from the mysql-common package to the mysql-community-server-core package, the same package as mysqld and more consistent with RPM packaging. (Bug #32752147)

  • Some queries making use of MATCH() within a HAVING clause were not handled correctly. (Bug #32616816, Bug #32934558, Bug #34782389)

  • A CREATE VIEW statement that contained a subquery sometimes led to an assertion in debug builds. (Bug #108783, Bug #34703610)

  • The deduction of data types for dynamic parameters passed as parameters to a user-defined SQL function was correct only for a single parameter; with more than one parameter, no such deduction was performed for the second and following parameters, with the result that their types were always reported erroneously to clients as MYSQL_TYPE_INVALID. (Bug #108545, Bug #34629157)

  • The internal function clone_os_copy_file_to_buf() did not advance the buffer position in the event of a partial read.

    Our thanks to Laurynas Biveinis for the contribution. (Bug #108317, Bug #34543194)

  • Views that access system views could encounter an access-denied error during normal use if the pushdown condition included expressions that used native functions from the system view. (Bug #108202, Bug #34515868)

  • When using window functions, the current row could reevaluate itself based on the wrong record in some cases. (Bug #108008, Bug #34431996)

  • A condition pushdown into a UNION of queries having LIKE clauses did not preserve the correct character set, leading to an (erroneous) empty result.

    We solve this problem in two parts:

    1. By refactoring resolution of LIKE expressions, in which character set determination and propagation were previously performed in two separate blocks of the code that were not always consistent with one another.

    2. By adding, in the internal parse_expression() function, a character set prefix to any literal character string that is cloned.

    (Bug #107787, Bug #34359297, Bug #34589153)

  • The audit_log server-side plugin always logged an entire multiple query, rather than logging only the specific part of the query that was executed. Changing when the query length is set resolves the issue. (Bug #107390, Bug #34207811)

  • Following an upgrade to MySQL 8.0.27 a specific query started consuming comparatively high amounts of memory whenever it was run within a stored procedure. (Bug #107327, Bug #34190122)

  • When a mysqld startup option was used with the maximum- prefix, the upper bound for the corresponding system variable was set but its current value was not checked against or adjusted according to the new limit and thus could in some cases be greater than the stated maximum. We fix this by adjusting the current value if it is larger than the new user defined maximum value. (Bug #99029, Bug #31072098)

  • The mysql_stmt_close() C API function could stop responding after a prepared statement was canceled using KILL QUERY. (Bug #84470, Bug #25584097)


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