The database cache was not flushed properly following execution of
DROP USER
. (Bug #37132323)Failed password validation was not always handled correctly. (Bug #37041439)
-
Process memory usage grew when the
libmysqlclient
API user tried to cache and reuse a prepared statement, preparing it once and then calling either ofmysql_stmt_bind_param()
ormysql_stmt_bind_named_param()
followed bymysql_stmt_execute()
, repeatedly without calling the matchingmysql_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 tomysql_stmt_bind_param()
ormysql_stmt_bind_named_param()
. (Bug #37202066)
-
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 usedutf8
as its connection and client character set, the view contained literal values with non-ASCII characters, and the query performed a condition pushdown into aUNION
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.
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 ofgsl::span
forstd::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 supersedesCMakeError.log
. References toCMakeError.log
have therefore been removed. (Bug #37305289)Implemented the standards-compliant
my_char_traits<unsigned char>
for use as a drop-in replacement forstd::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 filesql/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 fromplugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/task.cc
even thoughstd::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)
-
INSTALL COMPONENT
issued concurrently with aSET PERSIST
which used a subquery could sometimes lead to an unplanned exit of the server. (Bug #36559078)References: See also: Bug #35647759.
In some cases, after performing an upgrade, stored procedures relating to MySQL Enterprise Firewall were not processed correctly. (Bug #36084822)
When upgrading from MySQL 5.7 to a later MySQL release series, the system-created
mysql.sys
andmysql.session
accounts are now modified to use thecaching_sha2_password
authentication plugin instead of themysql_native_password
plugin, which is deprecated in MySQL 8.0, and removed in MySQL 9.0. (Bug #36608160)
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)
-
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 ofsystem 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 thePERFORMANCE_SCHEMA.METADATA_LOCKS
table.Our thanks to George Ma and the Alibaba team for the contribution. (Bug #116625, Bug #37271768)
Binary packages that include
curl
rather than linking to the systemcurl
library have been upgraded to usecurl
8.11.1. (Bug #37389565)
-
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 theINPLACE
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 anFTS_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 theINPLACE
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 anUPDATE
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 rebuildsInnoDB
tables using theINPLACE
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
withADD COLUMN
orDROP COLUMN
against an empty table now uses theINPLACE
algorithm by default instead ofINSTANT
. 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 theINPLACE
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 toOFF
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()
wheneverautocommit=OFF
to prevent table access deadlocks when an info repository transaction is executed after changingSOURCE_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 bySTART REPLICA
)While initializing dump thread for replica with UUID
has been improved touuid
, found a zombie dump thread with the same UUID. Source is killing the zombie dump thread(thread_id
)Upon reconnection with the replica, while initializing the dump thread for UUID
. (Bug #84358, Bug #25330090)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-
Group Replication: Removed a potential race condition between the internal functions
cs::apply::Commit_order_queue::front()
andcs::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 aView_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
, andER_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 inmle::validate()
andvalidate_session_options()
. (Bug #37267887)In
sql/item_cmpfunc.cc
,Item_bool_func2::resolve_type()
made an unchecked call toItem_bool_func::resolve_type()
; the call toItem_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 toa 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
was rejected withname
ER_BAD_TABLE_ERROR
if there existed a table with the samename
. (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, withDISTINCT
orGROUP 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)