MySQL 8.4 Release Notes  /  Changes in MySQL 8.4.4 (2025-01-21, LTS Release)

Changes in MySQL 8.4.4 (2025-01-21, LTS Release)

Account Management Notes

  • The database cache was not flushed properly following execution of DROP USER. (Bug #37132323)

  • Failed password validation was not always handled correctly. (Bug #37041439)

C API Notes

  • Process memory usage grew when the libmysqlclient API user tried to cache and reuse a prepared statement, preparing it once and then calling either of mysql_stmt_bind_param() or mysql_stmt_bind_named_param() followed by mysql_stmt_execute(), repeatedly without calling the matching mysql_stmt_close(), or calling it in the distant future (on application exit, for example).

    We solve this by introducing a separate MEM_ROOT object for storing the bind parameters array, which object can be cleared (deallocating the memory) on each call to mysql_stmt_bind_param() or mysql_stmt_bind_named_param(). (Bug #37202066)

Character Set Support

  • Zero rows resulted (where one row was expected) when selecting from a view created with its connection and client character set to latin1, where a query on the view used utf8 as its connection and client character set, the view contained literal values with non-ASCII characters, and the query performed a condition pushdown into a UNION of query blocks of the view.

    This problem was related to a previous issue which fixed an error for a similar problem: The problem in that case was properly considering the character set of the view definition when pushing down conditions contained in the view to inner query blocks, but the fix implemented at that time did not take into account the possibility that the view might contain non-ASCII characters.

    This meant that the condition to be pushed down was written to a text string with the wrong character set. We fix this oversight by ensuring that the string is created with the correct character set. (Bug #37111452)

    References: See also: Bug #36246859.

Compilation Notes

  • macOS: Removed obsolete CMake code from MacOS builds. (Bug #37258036)

  • macOS: It is now possible to build MySQL using the Homebrew version of Clang. (Bug #37256912)

  • macOS: Removed warnings of the form ld: warning: ignoring duplicate libraries and warnings specific to xcodebuild. (Bug #37065301)

  • Microsoft Windows: Disabled windows compiler warnings C26445 and C26821 in cmake/msvc_cppcheck.cmake. Both of these relate to MSVC substitution of gsl::span for std::span, which is not used for MySQL. (Bug #37158156)

  • Solaris: The minimum required version of GCC to build MySQL on Solaris has been raised to 11.4. See Source Installation Prerequisites, for more information. (Bug #37256600)

  • Starting with CMake 3.26, CMake writes the file CMakeFiles/CMakeConfigureLog.yaml, which supersedes CMakeError.log. References to CMakeError.log have therefore been removed. (Bug #37305289)

  • Implemented the standards-compliant my_char_traits<unsigned char> for use as a drop-in replacement for std::char_traits<unsigned char>, which was deprecated in Clang 18 and removed in Clang 19. (Bug #37273525)

  • Removed a maybe-uninitialized error found in sql/item.cc when building MySQL with GCC 14. (Bug #37157201)

  • The version of libedit used to compile MySQL was upgraded to 20240808-3.1. (Bug #37101293)

  • The server could not be built on Ubuntu 22.04 using Clang 13. (Bug #37075154)

  • Removed an error in mysql_prepare_create_table() (in the file sql/sql_table.cc) found when compiling MySQL with XCode 16. (Bug #37068527)

  • MySQL could not be compiled using Clang 19. (Bug #37014761)

  • #include <chrono> was missing from plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/task.cc even though std::chrono::duration_cast() was referenced in this file. (Bug #116779, Bug #37329617)

  • The server could not be built on Fedora 40 (and possibly other Linux platforms) using cmake 3.11, due to an issue with TIRPC. (Bug #116164, Bug #37080195)

Component Notes

  • INSTALL COMPONENT issued concurrently with a SET PERSIST which used a subquery could sometimes lead to an unplanned exit of the server. (Bug #36559078)

    References: See also: Bug #35647759.

Firewall Notes

  • In some cases, after performing an upgrade, stored procedures relating to MySQL Enterprise Firewall were not processed correctly. (Bug #36084822)

Installation Notes

  • When upgrading from MySQL 5.7 to a later MySQL release series, the system-created mysql.sys and mysql.session accounts are now modified to use the caching_sha2_password authentication plugin instead of the mysql_native_password plugin, which is deprecated in MySQL 8.0, and removed in MySQL 9.0. (Bug #36608160)

Optimizer Notes

  • Pushing down a condition which had an aggregate function in a WHERE clause caused the aggregate function to be evaluated when it should not have been. (Bug #36421735)

Performance Schema Notes

  • If a user other than root ran START REPLICA, PERFORMANCE_SCHEMA.PROCESSLIST assigned that user's name to the newly spawned foreground replication threads instead of system user.

    As of this release, system user is assigned to all foreground system threads. (Bug #37357562)

  • Under certain circumstances, a metadata lock can be upgraded or downgraded to a different LOCK_TYPE. This change was not reflected in the PERFORMANCE_SCHEMA.METADATA_LOCKS table.

    Our thanks to George Ma and the Alibaba team for the contribution. (Bug #116625, Bug #37271768)

Functionality Added or Changed

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

Bugs Fixed

  • Incompatible Change: Corruption occurred in a spatial index when an update of a geometry with a minimal change in the minimum bounding rectangle (MBR) was followed by a delete operation.

    When upgrading to this release, it is recommended that you drop any spatial indexes beforehand, then re-create them after the upgrade is complete. Alternatively, you can drop and re-create such indexes immediately following the upgrade, but before making use of any of the tables in which they occur. You should also be aware that downgrading to any previous version reintroduces the original problem described previously.

    For more information, see Creating Spatial Indexes. (Bug #36452528)

  • InnoDB: Concurrently truncating a table while querying the Performance Schema sometimes cause MySQL to halt unexpectedly. (Bug #37271715)

  • InnoDB: It was possible for an ALTER TABLE operation using the INPLACE algorithm on a table containing both a spatial index and an auto-increment column to cause corruption or, in debug builds, to trigger a debug assert. This was due to the auto-increment column value being overwritten in the old records of the spatial index while the new record was prepared. (Bug #37189985)

  • InnoDB: Certain IO buffer serializations triggered an assertion in debug builds that caused the system to hang. (Bug #37139618)

  • InnoDB: Improved InnoDB start up time. (Bug #36880863)

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

  • InnoDB: An assertion failure was raised when creating a FULLTEXT index on a table with an FTS_DOC_ID value greater than 4294967295. (Bug #36879147)

    References: See also: Bug #37387224.

  • InnoDB: Dropping a primary key, and then adding a new AUTO_INCREMENT column as a primary key in descending order using the INPLACE algorithm failed.

    Our thanks to Shaohua Wang and the team at Alibaba for the contribution. (Bug #36658450)

  • InnoDB: Extending a user tablespace produces file extension redo log records (MLOG_FILE_EXTEND), but they were not produced when extending the system tablespace. (Bug #36511673)

  • InnoDB: A DELETE operation on a table with a self referential foreign key and full-text index could have triggered an assertion. (Bug #36234681)

  • InnoDB: Common prefix compression for redo log inserts (MLOG_REC_INSERT) was disabled but is now enabled when the versions match. (Bug #34946626)

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

  • InnoDB: Virtual column information for a row containing an externally stored BLOB was not always logged during an UPDATE operation, which sometimes resulted in an Index PRIMARY is corrupted error. (Bug #34574604)

  • InnoDB: ON DELETE CASCADE with generated columns containing secondary indexes sometimes failed, due to virtual column templates not being initialized before deletion.

    Our thanks to Rahul Malik for the contribution. (Bug #33691659)

  • InnoDB: An update operation attempted to update a virtual column while building an update node for a child table, but should not have done so since foreign key constraints cannot reference virtual columns. (Bug #33327093)

  • InnoDB: It was possible for ALTER TABLE, which rebuilds InnoDB tables using the INPLACE algorithm, to be rejected with a duplicate key error due to a non-duplicate record being inserted concurrently while the rebuild was paused to release a page latch.

    Our thanks to Dmitry Lenev and the team at Percona for contributing to this fix. (Bug #115511, Bug #36808088)

  • InnoDB: The check enforcing the rule that ALGORITHM=INSTANT cannot be used on a column referenced by a foreign key constraint from another table did not inspect the last field of said constraint. (Bug #115457, Bug #36796094)

  • InnoDB: CPU usage statistics did not account for a processor count over 128, which could degrade performance on these larger systems. (Bug #115399, Bug #36765223)

  • InnoDB: Executing ALTER TABLE with ADD COLUMN or DROP COLUMN against an empty table now uses the INPLACE algorithm by default instead of INSTANT. This change means the row version is no longer incremented for these simple operations. (Bug #113051, Bug #36004394)

  • InnoDB: An ALTER TABLE operation that rebuilt an InnoDB table using the INPLACE algorithm potentially led to losing a row of data if a purge occurred concurrently on the altered table that contained a clustered or spatial index.

    Our thanks to Dmitry Lenev and the team at Percona for contributing to this fix. (Bug #110706, Bug #113812, Bug #115608, Bug #116764, Bug #35303494, Bug #36261480, Bug #36846567, Bug #37318367)

  • InnoDB: Queries with a descending primary key and the index_merge optimization sometimes yielded incorrect results such as missing rows. (Bug #106207, Bug #33767814)

  • Replication: In an InnoDB ClusterSet setup, when autocommit was set to OFF on all nodes in the cluster, a controlled switchover using MySQL Shell was rejected with Error 1105 (Unknown error).

    To fix this, we now force a new transaction in channel_change_source_connection_auto_failover() whenever autocommit=OFF to prevent table access deadlocks when an info repository transaction is executed after changing SOURCE_CONNECTION_AUTO_FAILOVER. (Bug #37173907)

  • Replication: While large transactions were being received and applied, and a request to stop the replication channel was made using STOP REPLICA, MySQL did not do so properly, and subsequently did not process any channel commands. In addition, the server shutdown process did not complete gracefully, and required either the MySQL process to be killed or the host system to be restarted. (Bug #115966, Bug #37008345)

  • Replication: The log message written when a replica reconnects to the source (when, for example, it is stopped and restarted by issuing STOP REPLICA followed by START REPLICA) While initializing dump thread for replica with UUID uuid, found a zombie dump thread with the same UUID. Source is killing the zombie dump thread(thread_id) has been improved to Upon reconnection with the replica, while initializing the dump thread for UUID uuid, an existing dump thread with the same UUID was detected. The source is terminating the previous dump thread (thread_id), which is normal and expected. (Bug #84358, Bug #25330090)

  • Group Replication: Removed a potential race condition between the internal functions cs::apply::Commit_order_queue::front() and cs::apply::Commit_order_queue::remove(). (Bug #37223451)

    References: See also: Bug #35206392.

  • Group Replication: When the primary node unexpectedly left the group and quickly attempted to rejoin, the member which had been elected to remove other, faulty members tried to expel or remove the faulty node but could not do so due to lack of a majority. When the expelled or removed node was the primary, this left the cluster without a primary, resulting in an unusable state. (Bug #36991859)

    References: See also: Bug #37181867.

  • Group Replication: In some cases, adding a new secondary caused existing secondaries to lag, leading to a deadlock which persisted with no more writes possible until the primary was restarted.

    This deadlock occurred between the ticket manager, which ensures that transactions are committed on the correct side of a view change (before or after the view change), and the commit order manager on the inbound replication channel, which ensures that transactions are committed in the same order in which they are received, when these two managers required different orders. This meant that, in some cases, adding a new secondary caused the group primary to be unable to do writes.

    We solve this issue by ignoring the commit order manager ordering and enforcing the ticket manager ordering for non-conflicting transactions when such a deadlock occurs. A consequence of this is that replica_preserve_commit_order may not be strictly honored near a View_change_log_event. In other words, replica_preserve_commit_order no longer provides a strict guarantee on an inbound channel on a Group Replication primary. replica_preserve_commit_order still ensures that transactions are ordered correctly, with the only exception being non-conflicting transactions around view change log events. (Bug #35206392)

    References: See also: Bug #37223451.

  • Group Replication: Improved garbage collection in Group Replication by eliminating non-essential calls to is_subset_not_equals(). (Bug #110673, Bug #35286974)

  • Group Replication: Removing a group member from a group in which all members were running the same version of MySQL, upgrading it to a later version (from a later release series), and then requesting it to rejoin the group caused the upgraded group member to hang in the recovering state.

  • The errors ER_DD_UPDATE_DATADIR_FLAG_FAIL, ER_IB_MSG_FIL_STATE_MOVED_PREV_OR_HAS_DATADIR, ER_RPL_KILL_OLD_DUMP_THREAD_ENCOUNTERED, and ER_RPL_MTA_ALLOW_COMMIT_OUT_OF_ORDER were originally defined in MySQL 8.0, but were subsequently assigned different error code numbers (but with the same names) in MySQL 8.4. The numbers assigned in MySQL 8.0 now apply to MySQL 8.0 only; in the MySQL 8.4 and later release series, only the numbers assigned in MySQL 8.4 are used. (Bug #37284176)

  • Added missing checks for NULL input arguments in mle::validate() and validate_session_options(). (Bug #37267887)

  • In sql/item_cmpfunc.cc, Item_bool_func2::resolve_type() made an unchecked call to Item_bool_func::resolve_type(); the call to Item_bool_func::resolve_type() ignored its return value, and execution continued even in case of an error. (Bug #37143289)

  • AppArmor denied access to /proc/$pid/task/$thread_id/mem, a file required to generate a stack trace. (Bug #37063288)

    References: See also: Bug #37387034.

  • A filter condition in a subquery was sometimes ignored when a query used the index_subquery join type for subquery execution, and the subquery table used materialization in the execution plan. The derived table access path replaced the filter condition, resulting a final plan without the filter layer. To fix this, in such cases, we now add the derived table access path along with the filter access path instead of replacing the latter. (Bug #36918913)

  • Some UNION operations similar to a UNION b UNION c ... consumed excessive memory. To help keep this from happening, we now flatten equal set operations at the parsing level, before contextualization occurs, which should result in reduced resource usage by such operations. (Bug #36652610)

  • Improved the internal function my_print_help(). (Bug #36615714)

    References: See also: Bug #37387224.

  • Removed incorrect code from Acl_cache. (Bug #36608160)

  • A subquery containing an aggregate function WITH ROLLUP which was part of a row value comparator was not always processed correctly. (Bug #36593235)

    References: See also: Bug #37387180. This issue is a regression of: Bug #30969045, Bug #30921780, Bug #26227613, Bug #29134467, Bug #30967158.

  • It was possible for errors raised when persisting variables not to be reported correctly. (Bug #36574732)

  • Some subqueries using WITH ROLLUP were not always processed correctly. (Bug #36421704)

  • MyISAM block length calculations were not always performed correctly. (Bug #36347992)

  • Fixed an issue relating to FTS and concurrent DDL or DML. (Bug #34633727)

  • DROP VIEW name was rejected with ER_BAD_TABLE_ERROR if there existed a table with the same name. (Bug #33200087)

  • Incorrect results were returned by some queries that used hash antijoins when the hash table did not fit in the join buffer and spilled to disk. (The query triggering the issue actually specified LEFT JOIN, but this was transformed internally from a left outer join to an antijoin.)

    The problem was that some rows in the probe table were skipped when writing the probe rows to chunk files, the skipped rows being those that had NULL in part of the join key. Such rows can be skipped for inner joins and semijoins, as they are known to have no match in the build table, but for outer joins and antijoins, rows in the probe table which have no matching row in the build table should be part of the join result, so they must be included in the chunk files.

    We already preserved these rows in the chunk files for outer joins. This fix extends the logic used for that purpose so that it also applies for antijoins. (Bug #116334, Bug #37161583)

  • In MySQL 8.0 and later, queries of the form SELECT DISTINCT ... FROM t1 WHERE NOT IN(SELECT ...) were transformed into an antijoin if possible, causing the optimizer not to choose a group skip scan for table t1 whereas it would have been chosen in MySQL 5.7. This resulted in a performance degradation for such queries. Group skip scan is not chosen, since the query is now no longer a single-table query following the antijoin transformation, and this access method is enabled only for single table queries. The same behaviour can be seen for queries which are transformed into semijoins as well. In such cases, group skip scan access method can still be used if the access method is used only for duplicate removal (that is, with DISTINCT or GROUP BY, but without aggregate functions).

    To fix this, we enable group skip scan when there is only one table in the original query, irrespective of the number of semijoin tables present after internal transformations as long as the query contains no aggregate functions. (Bug #112362, Bug #35842412)

  • The mysql client did not allow using '#' or '--' inside an optimizer hint comment.

    Our thanks to Kaiwang Chen for the contribution. (Bug #98521, Bug #30875669)