Changes in MySQL 8.0.37 (2024-04-30, General Availability)

• Audit Log Notes

• Character Set Support

• Compilation Notes

• Component Notes

• Optimizer Notes

• Performance Schema Notes

• Functionality Added or Changed

• Bugs Fixed

Audit Log Notes

• MySQL now calls plugin->deinit() with a valid plugin struct as an argument regardless of the plugin's type.

  Our thanks to Martin Alderete for the contribution.

Character Set Support

• When the character_set_server system variable was set using SET PERSIST or SET GLOBAL, it did not take effect for new client sessions or for a client establishing a connection to the server after the server was restarted. The only workaround was to set the corresponding command-line option when starting the server.

  To fix this, we now make sure that, at the time of server restart, the configuration data is read in the correct order so that the variable setting takes effect as expected. (Bug #35529604)

Compilation Notes

• Warnings for unused variables are turned into compilation errors when compiling with -DMYSQL_MAINTAINER_MODE=1. To avoid this use -DMYSQL_MAINTAINER_MODE=0 to disable such errors. (Bug #113662, Bug #36198423)

• Improved the cycle timer for the s390x architecture.

  Our thanks to Jonathan Albrecht for the contribution. (Bug #112845, Bug #35949958)

Component Notes

• The values for component options set using the --loose prefix were not read when the component was installed. (Bug #28341329)

Optimizer Notes

• The multi-range read (MRR) optimization did not perform as well as in previous releases. (Bug #113711, Bug #36220640)

Performance Schema Notes

• User variables assigned decimal values were rounded up in the user_variables_by_thread table. (Bug #35781732)

• Executing SELECT * from performance_schema.data_locks on a server under heavy load could cause MySQL to consume too much memory and close unexpectedly.

  As of this release, memory used executing such a query is now instrumented with memory/performance_schema/data_container, enabling you to observe memory consumption. (Bug #35240825)

• Executing SELECT * from performance_schema.data_locks on a server under heavy load could cause a deadlock in InnoDB. (Bug #35068461)

  References: See also: Bug #35240825.

Functionality Added or Changed

• Important Change; Group Replication: When issued with group_replication_consistency set to BEFORE_ON_PRIMARY_FAILOVER, the MySQL KILL statement now ignores any consistency guarantees, with any interrupted transactions now being rolled back.

• Important Change: For platforms on which OpenSSL libraries are bundled, the linked OpenSSL library for MySQL Server has been updated to version 3.0.13. Issues fixed in OpenSSL version 3.0.13 are described at https://openssl-library.org/news/openssl-3.0-notes/. (Bug #36261675)

• Packaging: Added support for Fedora 40 and Ubuntu 24.04.

• Microsoft Windows: MySQL Windows binary files (.exe and .dll files) now display additional information when their properties are viewed. (Bug #36379291)

• Clone plugin version requirements have been relaxed to allow cloning between different point releases in the same series. In other words, only the major and minor version numbers must match when previously the release number also had to match.

  For example, cloning of MySQL 8.0.37 to (a future) MySQL 8.0.42, or the reverse, is supported. Previous restrictions still apply to versions older than 8.0.37, for example, so cloning of MySQL 8.0.36 to any other MySQL release (or from a different MySQL release to 8.0.36) remains unsupported.

  For more information, see The Clone Plugin. (Bug #36293529, WL #15989)

Bugs Fixed

• Important Change: The Robin Hood hashing library has been replaced with unordered_dense. (Bug #36158022)

• InnoDB; Microsoft Windows: Improved redo log performance on Windows by opening redo log files in overlapped mode. (Bug #36154818)

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

• InnoDB: The log writer calls functions that temporarily release log.writer_mutex; when innodb_log_writer_threads=OFF, this potentially led to other threads writing to the redo log in between these times. (Bug #36425219)

• InnoDB: Some FTS operations on tables with FTS indexes led to inconsistent results. For example, if the server terminated while synchronizing the FTS cache or when synchronization occurred concurrently with another FTS operation.

  Our thanks to Yin Peng and the Tencent team for the contribution. (Bug #36347647)

• InnoDB: When creating an index on a table containing data, valgrind occasionally reported reads of uninitialized memory from ddl::Builder::bulk_add_row(). (Bug #36342792)

• InnoDB: On Windows, keeping a file open without a shared write lock and attempting to acquire the fil_shard mutex caused a deadlock with another thread that had acquired the fil_shard mutex and was attempting to access the same file. (Bug #36159317)

  References: See also: Bug #32808809.

• InnoDB: Fixed a potential redo log rotation issue that could emit a "Found existing redo log files, but at least one is missing" error during recovery. (Bug #36124625)

• InnoDB: Improved os_innodb_umask handling, and made it read-only. (Bug #35932118)

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

• InnoDB: Found and fixed an assertion failure related to full-text indexes. (Bug #35836581)

• InnoDB: Improved buffer handling during the tablespace deletion process, a situation that could have potentially caused an assertion failure. (Bug #35676106, Bug #36343647)

• InnoDB: If a MySQL table in a system schema had an INSTANT ADD column that was added before 8.0.29 (they are not allowed as of that version), and after MySQL was upgraded to a version greater than 8.0.29, DMLs on these tables would result in the server unexpectedly closing.

  Our thanks to Richard Dang for the contribution. (Bug #35625510, Bug #35981565, Bug #36180360)

• InnoDB: The redo log would potentially not log a column order change with instant DDL, which could cause an incorrect log replay during recovery. (Bug #35183686)

• InnoDB: Results for SHOW ENGINE INNODB STATUS showed an invalid value (NULL) as the first result. (Bug #113819, Bug #36118112)

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

• InnoDB: With innodb_parallel_read_threads set to a value greater than 1, InnoDB unnecessarily disabled read-ahead heuristics which resulted in stalls when pages were not already in the buffer pool. (Bug #113482, Bug #36142806)

• InnoDB: Running a query that used a unique hash index with the TempTable storage engine could take significantly more time compared to running the query with the MEMORY engine.

  Our thanks to xiaoyang chen for the contribution. (Bug #113178, Bug #36037224, Bug #36224958)

• InnoDB: In debug builds, there was an assertion failure in InnoDB's background when a transaction it wanted to acquire an MDL lock on was no longer active.

  This fix is based on a patch from Genze Wu with Alibaba, thank you for the contribution. (Bug #112424, Bug #35835864)

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

• InnoDB: With innodb_parallel_read_threads set to a value greater than 1, InnoDB would unnecessarily request asynchronous reads which required more synchronization during I/O completion and created a bottleneck due to the limited number of available threads (innodb_read_io_threads) for handling I/O operations. Now this performs synchronous instead of asynchronous reads. (Bug #112137, Bug #35740866)

• InnoDB: A trx would unexpectedly halt after encountering an incorrect trx->in_innodb value.

  Our thanks to Shaohua Wang for the contribution. (Bug #110652, Bug #35277407)

• InnoDB: SELECT ... GROUP BY queries were at least twice as slow with the TempTable engine than the Memory engine. (Bug #107700, Bug #34338001)

• InnoDB: MySQL no longer ignores the optimizer hint to use a secondary index scan, which instead forced a clustered (parallel) index scan. (Bug #100597, Bug #112767, Bug #31791868, Bug #35952353)

• Group Replication: Problems arose when members M1 and M2 were in a group, with M1 using u1 as its recovery user and M2 using u2 as its own recovery user, and both users u1 and u2 existing on M1 and M2 with all necessary privileges, and when a new member M3 joined the group using u2 as its recovery user. M3 knew only of user u2, but did not know of user u1, leading START GROUP REPLICATION on M2 to be rejected since M1 was unable to connect to M2. This also generated a new view_id listing the group members as M1 and M2, but M1 nevertheless continued trying to connect to M3, with M1 logging Error in establishing mysql connection and M3 logging Access denied errors for the connection attempts from M1.

  By design, XCom stores the last three known configurations, including references to physical connections shared among all past and present configurations. This is done to facilitate quick reconnections by nodes rejoining the group, explicitly or implicitly, and that were already present in any of those configurations.

  A side effect of this was that we might keep attempting to connect to a node that was currently not in the group. To solve this problem, we inhibit error logging if the node is not in the current configuration, in order to avoid false negatives which might lead a DBA or an operator to think mistakenly that there is a problem in the system. (Bug #36210988)

  References: See also: Bug #32592027.

• Group Replication: Improved handling of GTID sets. (Bug #36093405)

• Group Replication: Two cases were found in which a member exited the group and moved to the ERROR state, but did not honor the action specified by group_replication_exit_state_action; these are listed here:

  • When an error occurred while enabling super_read_only

  • When member join recovery was not possible, due to missing binary logs and clone groups on group members

  Example: When the value of group_replication_exit_state_action was OFFLINE_MODE and one of these events took place, offline mode was not enabled as expected. (Bug #36076308)

• Group Replication: After successfully setting a new primary, group_replication_set_as_primary() in some cases waited indefinitely for the operation to complete. (Bug #36059098)

• JSON: JOIN and GROUP BY handled some JSON column values differently. (Bug #101048, Bug #31969607)

• MySQL NDB ClusterJ: The setLimits() method can now be chained to deletePersistentAll() to limit the number of items to delete. See the description of deletePersistentAll() for details. (Bug #36049906)

• Updated BuildRequire rules to align with versions now required for CMake and Bison. (Bug #36343254)

• SET GLOBAL offline_mode=ON did not always perform correctly when issued under high loads. (Bug #36275182)

  References: See also: Bug #36405894.

• Upgraded curl to version 8.6.0. (Bug #36267545)

• mysqldump did not always interpret the server version correctly. (Bug #36248967)

  References: See also: Bug #36405879.

• Condition pushdown to a view was rejected with a collation mismatch if the view was created with a different character set than the character set used when querying the view. (Bug #36246859)

• Use of the deprecated exec_program() command has been replaced by execute_process() to provide compatibility with CMake 3.28.1 and later. (Bug #36220656)

• Upgraded the protobuf library to version 25.1. (Bug #36108397)

• For building Enterprise Linux RPMs, the build scripts now point to a newer strip command (under /opt/rh/gcc-toolset-12), and they now check that the corresponding dwz tool is available. Previously this was only implemented for EL8. (Bug #36090069)

• We now look for gcc-ar and gcc-ranlib when building on Oracle Linux with link-time optimization. (Bug #36089900)

• The server sometimes terminated unexpectedly in response to a specific query. (Bug #35957627)

• In certain cases, a lateral join was not handled correctly. (Bug #35945239)

  References: See also: Bug #107700, Bug #34338001. This issue is a regression of: Bug #32644631.

• Improved view and trigger definer handling by view and table DDL. (Bug #35942937)

• The server did not always return metadata to the client correctly for certain queries. (Bug #35904044)

• When running queries against a table with a multi-value index, the server sometimes exited unexpectedly, often while executing a complex SELECT query which used this index. (Bug #35789759)

• Improved code in sql/item_subselect.cc. (Bug #35733778, Bug #35738531, Bug #35779012)

• CREATE USER IF EXISTS was not always logged correctly. (Bug #35530823)

• The server did not disallow subqueries in partition expressions properly. These are invalid, and should cause a syntax error. (Bug #35476172)

• Some RANK() ... OVER() queries raised an assertion in sql/sql_executor.cc. (Bug #35228083)

• When successive ALTER TABLE ... ALGORITHM=COPY statements were issued within 10 seconds of one another, the n_rows value became 0. (Bug #35127747)

• Updated the URL used for downloading the Boost C++ libraries. (Bug #113576, Bug #36164514)

• The fix for a previous issue, first addressed in MySQL 8.0.30, was incomplete.

  Our thanks to Hao Lu for the contribution. (Bug #113174, Bug #36035044)

  References: This issue is a regression of: Bug #110801, Bug #35328028.

• On s390x, we now compile the FMA test with -O2 to avoid overoptimization.

  Our thanks to Jonathan Albrecht for the contribution. (Bug #113096, Bug #36016140)

• Although s390x is a big-endian platform, the little-endian ICU data directory was used for compiling.

  Our thanks to Jonathan Albrecht for the contribution. (Bug #113095, Bug #36016141)

• Incorrect results were sometimes obtained from a query that used a group by loose index scan. (Bug #112541, Bug #35854362)

• An assertion failed in debug builds when inserting data with a zero-length column, such as CHAR(0) or BINARY(0), into a table. Now, a less strict assertion more accurately fails only if it detects that a non-zero number of bytes copied from a source is identical to the target. (Bug #111450, Bug #35507763)

• A VALUES statement in a correlated lateral or (other) dependent subquery yielded an incorrect result. (Bug #109252, Bug #110076, Bug #34852090, Bug #35087820)

• IN should return NULL not only if the expression on the left hand side is NULL, but when no match is found in the list and one of the expressions in the list is NULL as well. In some cases, it was found that adding rows to a table caused a subsequent prepared SELECT NULL IN (SELECT ...) query to return a different result when the result should have remained the same. (Bug #94857, Bug #29602835)