MySQL 8.4 Release 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)
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)
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.
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)
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.
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
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 #36608636)
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 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)
Binary packages that include curl
rather than
linking to the system curl
library have been
upgraded to use curl
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 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: When clearing an AHI index from all buffer pool pages, the block state would potentially change to BUF_BLOCK_MEMORY before acquiring the block mutex thus causing an unexpected halt. (Bug #35037114)
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
has been
improved to uuid
, 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()
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
was rejected with
name
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)