Functionality Added or Changed
SHA2() function now returns a
character string with the connection character set and
collation. Previously, it returned a binary string. This is the
same change made for several other encryption functions in MySQL
The mechanism that checks if there is enough space for redo logs
was improved, reducing the chance of encountering this message:
ERROR: the age of the last checkpoint is
x, which exceeds the log group
InnoDB: Improved performance and scalability on Windows systems, especially for Windows Vista and higher. Re-enabled the use of atomic instructions on Windows systems. For Windows Vista and higher, reduced the number of event handles used. To compile on Windows systems now requires Windows SDK v6.0 or later; either upgrade to Visual Studio 2008 or 2010, or for Visual Studio 2005, install Windows SDK Update for Windows Vista. (Bug #22268)
Overhead for the Performance Schema interface was reduced. (Bug #55087)
MySQL-shared-compat RPMs for
Linux contained both the current and previous client library
versions for the target platform. Thus, the package contents
MySQL-shared RPMs, which
contain only the current client library version. This can result
in problems in two cases:
MySQL-shared RPM is installed
but later it is determined that the
MySQL-shared-compat RPM is needed (an
application is installed that was linked against an older
client library). Installing the
MySQL-shared-compat RPM results in a
conflict because both include the current library version.
This can be overcome by using the
option to RPM, or by first uninstalling the
MySQL-shared RPM (which breaks
MySQL-shared-compat RPM is
installed, but old applications that require it are removed
or upgraded to the current library version. In this case,
MySQL-shared-compat cannot be replaced
MySQL-shared as long as current
applications are installed. This can be overcome by using
--force option to RPM, which incurs the
risk of breaking dependencies.
MySQL-shared-compat RPMs include only
older client library versions and no longer include the current
version, so that the
MySQL-shared-compat RPM contents no longer
MySQL-shared-compat RPM can be
installed even if the
MySQL-shared RPM is
installed, without producing conflicts related to the current
library version. The
can be uninstalled when old applications are removed or upgraded
to the current library version, without breaking applications
that already use the current library version.
If you previously installed the
MySQL-shared-compat RPM because you needed
both the current and previous libraries, you should install both
MySQL-shared-compat RPMs now.
References: See also Bug #12368215.
REPAIR TABLE and
OPTIMIZE TABLE table now catch
and throw any errors that occur while copying table statistics
from the old corrupted file to newly created file. For example.
if the user ID of the owner of the
.MYI file is
different from the user ID of the mysqld
REPAIR TABLE and
OPTIMIZE TABLE generate a "cannot
change ownership of the file" error unless
mysqld is started by the
(Bug #61598, Bug #13600058)
Within stored programs,
LIMIT clauses now
permit integer-valued routine parameters or local variables as
Code was removed for the following no-longer-supported platforms: NetWare, MS-DOS, VMS, QNX, and 32-bit SPARC.
Security Fix; InnoDB:
After changing the values of the
parameters, DDL statements could cause a server crash.
(Bug #55039, CVE-2010-3676)
Queries could cause a server crash if the
LEAST() function had a mixed list
of numeric and
arguments, and the result of such a function was processed using
an intermediate temporary table.
(Bug #54461, CVE-2010-3838)
During evaluation of arguments to extreme-value functions such
GREATEST(), type errors did not
propagate properly, causing the server to crash.
(Bug #55826, CVE-2010-3833)
Security Fix: The server could crash after materializing a derived table that required a temporary table for grouping. (Bug #55568, CVE-2010-3834)
Security Fix: Queries with nested joins could cause an infinite loop in the server when used from stored procedures and prepared statements. (Bug #53544, CVE-2010-3839)
ROLLUP together could cause a server crash.
(Bug #54476, CVE-2010-3837)
LIKE predicates during view
preparation could cause a server crash.
(Bug #54568, Bug #11762026, CVE-2010-3836)
A user-variable assignment expression that is evaluated in a
logical expression context can be precalculated in a temporary
GROUP BY. However, when the
expression value is used after creation of the temporary table,
it was re-evaluated, not read from the table, and a server crash
(Bug #55564, CVE-2010-3835)
EXPLAIN with queries of the
SELECT ... UNION ... ORDER BY (SELECT ... WHERE
...) could cause a server crash.
(Bug #52711, CVE-2010-3682)
InnoDB tables with nullable columns
could cause a server crash.
(Bug #54044, CVE-2010-3680)
A malformed argument to the
BINLOG statement could result in
Valgrind warnings or a server crash.
(Bug #54393, CVE-2010-3679)
Incorrect handling of
NULL arguments could
lead to a crash for
CASE operations when
NULL arguments were either passed explicitly
as arguments (for
implicitly generated by the
(Bug #54477, CVE-2010-3678)
Joins involving a table with a unique
SET column could cause a server
(Bug #54575, CVE-2010-3677)
Security Fix: A security bug was fixed. (Bug #49124)
produce slower performance for some operations than the previous
EXPLAIN plan for an
InnoDB table could vary greatly in the
estimated cost for a
Incompatible Change; Replication:
As of MySQL 5.5.6, handling of
TABLE IF NOT EXISTS ... SELECT statements has been
changed for the case that the destination table already exists:
TABLE IF NOT EXISTS ... SELECT, MySQL produced a
warning that the table exists, but inserted the rows and
wrote the statement to the binary log anyway. By contrast,
TABLE ... SELECT (without
EXISTS) failed with an error, but MySQL inserted
no rows and did not write the statement to the binary log.
MySQL now handles both statements the same way when the
destination table exists, in that neither statement inserts
rows or is written to the binary log. The difference between
them is that MySQL produces a warning when
EXISTS is present and an error when it is not.
This change in handling of
IF NOT EXISTS
results in an incompatibility for statement-based replication
from a MySQL 5.1 master with the original behavior and a MySQL
5.5 slave with the new behavior. Suppose that
TABLE IF NOT EXISTS ... SELECT is executed on the
master and the destination table exists. The result is that rows
are inserted on the master but not on the slave. (Row-based
replication does not have this problem.)
To address this issue, statement-based binary logging for
TABLE IF NOT EXISTS ... SELECT is changed in MySQL 5.1
as of 5.1.51:
If the destination table does not exist, there is no change: The statement is logged as is.
If the destination table does exist, the statement is logged
as the equivalent pair of
TABLE IF NOT EXISTS and
SELECT statements. (If the
SELECT in the original
statement is preceded by
This change provides forward compatibility for statement-based replication from MySQL 5.1 to 5.5 because when the destination table exists, the rows will be inserted on both the master and slave. To take advantage of this compatibility measure, the 5.1 server must be at least 5.1.51 and the 5.5 server must be at least 5.5.6.
To upgrade an existing 5.1-to-5.5 replication scenario, upgrade the master first to 5.1.51 or higher. Note that this differs from the usual replication upgrade advice of upgrading the slave first.
A workaround for applications that wish to achieve the original
effect (rows inserted regardless of whether the destination
table exists) is to use
TABLE IF NOT EXISTS and
SELECT statements rather than
TABLE IF NOT EXISTS ... SELECT statements.
Along with the change just described, the following related
change was made: Previously, if an existing view was named as
the destination table for
TABLE IF NOT EXISTS ... SELECT, rows were inserted
into the underlying base table and the statement was written to
the binary log. As of MySQL 5.1.51 and 5.5.6, nothing is
inserted or logged.
(Bug #47442, Bug #47132, Bug #48814, Bug #49494)
Incompatible Change: Handling of warnings and errors during stored program execution was problematic:
If one statement generated several warnings or errors, only the handler for the first was activated, even if another might be more appropriate. Now the server chooses the more appropriate handler.
Warning or error information could be lost.
(Bug #36185, Bug #5889, Bug #9857, Bug #23032)
Incompatible Change: Several changes were made to Performance Schema tables:
SETUP_OBJECTS table was removed.
PROCESSLIST table was renamed to
table was renamed to
If the server was started with
character_set_server set to
utf16, it crashed during full-text stopword
initialization. Now the stopword file is loaded and searched
If any table was created with
indexes while the server character set was
utf32, it should be repaired using this
Important Change; Replication:
INFILE statement is now considered unsafe for
statement-based replication. When using statement-based logging
mode, the statement now produces a warning; when using
mixed-format logging, the statement is made using the row-based
Lock_time field in the slow query log now
reports a larger value, including the time for
InnoDB lock waits at the statement
InnoDB storage engine was not included in
the default installation when using the
The mysql_config tool did not output the
requirement for the
aio library for
Some memory used for
InnoDB asynchronous I/O
was not freed at shutdown.
InnoDB table with an auto-increment
column, the server could crash if the first statement that
references the table after a server restart is a
CREATE TABLE statement.
The server could crash during the recovery phase of startup, if
it previously crashed while inserting
other large columns that use off-page storage into an
InnoDB table created with
InnoDB table created with
ROW_FORMAT=DYNAMIC, a query using the
READ UNCOMMITTED isolation level could cause
the server to stop with an assertion error, if
BLOB or other large columns that use off-page
storage were being inserted at the same time.
InnoDB: For debug builds, the database server could crash when renaming a table that had active transactions. (Bug #54453)
Performing large numbers of
TABLE statements caused excessive memory use.
InnoDB could issue an incorrect message on
startup, if tables were created under the setting
innodb_file_per_table=ON. The message was of
InnoDB: Warning: allocated tablespace
you encounter this message after upgrading, create an
n, old maximum was 0
InnoDB table with
innodb_file_per_table = ON and restart the
server. The message should not be displayed any more. If you
continue to encounter this message, or if you get it and haven't
used a version without this fix, you might have corruption in
your shared tablespace. If so, back up and reload your data.
ALTER TABLE statement could
InnoDB compressed table (with
row_format=compressed) back to an
uncompressed table (with
The output from the
SHOW ENGINE INNODB
STATUS command now includes information about
“spin rounds” for RW-locks (both shared and
InnoDB could not create tables that
utf32 character set.
Misimplementation of the
os_fast_mutex_trylock() function in
InnoDB resulted in unnecessary
blocking and reduced performance.
Implementation of the 64-bit
InnoDB was not optimized for
64-bit processors, resulting in excessive storage and reduced
An assertion was raised if (1) an
InnoDB table was created using
TABLE ... SELECT where the query used an
INFORMATION_SCHEMA table and a view existed
in the database; or (2) any statement that modified an
InnoDB table had a subquery
References: See also Bug #53770.
TABLE ... TRUNCATE PARTITION, when called concurrently
with transactional DML on the table, was executed immediately
and did not wait for the concurrent transaction to release
locks. As a result, the
TABLE statement was written into the binary log before
the DML statement, which led to replication failures when using
References: See also Bug #42643.
Partitioning: When the storage engine used to create a partitioned table was disabled, attempting to drop the table caused the server to crash. (Bug #46086)
INSERT ON DUPLICATE KEY
UPDATE statements performed poorly on tables having
many partitions. The handler function for reading a row from a
specific index was not optimized in the partitioning handler.
References: This bug is a regression of Bug #39084.
TABLE ... REORGANIZE PARTITION and
SELECT could deadlock. There were
unreleased latches in the
ALTER TABLE ...
REORGANIZE PARTITION thread which were needed by the
SELECT thread to be able to
Replication: If the SQL thread was started while the I/O thread was performing rotation of the relay log, the two threads could begin to race for the same I/O cache, leading to a server crash. (Bug #54509)
References: See also Bug #50364.
The value of
had no effect on statements mixing transactional tables and
nontransactional tables, or mixing temporary tables and
As part of the fix for this issue, updates to temporary tables are now handled as transactional or nontransactional according to their storage engine types. (In effect, the current fix reverts a change made previously as part of the fix for Bug #53259.)
In addition, unsafe mixed statements (that is, statements which access transactional table as well nontransactional or temporary tables, and write to any of them) are now handled as transactional when the statement-based logging format is in use. (Bug #53452)
References: See also Bug #51894.
A number of statements generated unnecessary warnings as
potentially unsafe statements. (Due to the fix for Bug #51894, a
temporary table is treated in this context as a transactional
table, so that any mixed statement such as
flagged as unsafe.)
To reduce the number of spurious warnings produced when this happened, some of the criteria used to classify a statements as safe or unsafe have been changed. For more information about handling of mixed statements, see Transactional, nontransactional, and mixed statements. (Bug #53259)
References: See also Bug #53452, Bug #54872.
any statement that is flagged as being unsafe, possibly causing
the slave to go out of sync, generates a warning. This warning
is written to the server log, the warning count is returned to
the client in the server's response, and the warnings are
The current bug affects only the counts for warnings to the
client and that are visible through
WARNINGS; it does not affect which warnings are
written to the log. The current issue came about because the fix
for an earlier issue caused warnings for substatements to be
cleared whenever a new substatement was started. However, this
suppressed warnings for unsafe statements in some cases. Now,
such warnings are no longer cleared.
References: This bug was introduced by Bug #36649.
When using the row-based logging format, a failed
CREATE TABLE ...
SELECT statement was written to the binary log,
causing replication to break if the failed statement was later
re-run on the master. In such cases, a
DROP TABLE ... IF
EXIST statement is now logged in the event that a
CREATE TABLE ...
When using the row-based logging format, a
SET PASSWORD statement was
written to the binary log twice.
When closing temporary tables, after the session connection was
already closed, if the writing of the implicit
DROP TABLE statement into the
binary log failed, it was possible for the resulting error to be
mishandled, triggering an assertion.
ROW, then creating and dropping a temporary
table led to an assertion.
Replication: When using mixed-format replication, changes made to a nontransactional temporary table within a transaction were not written into the binary log when the transaction was rolled back. This could lead to a failure in replication if the temporary table was used again afterwards. (Bug #54872)
References: See also Bug #53259.
binlog_format was explicitly
ROW following the creation of a temporary
table, then on disconnection the master failed to write the
TEMPORARY TABLE statement into the binary log. As a
consequence, temporary tables (and their corresponding files)
accumulated as this scenario was repeated.
References: See also Bug #52616.
Replication: Two related issues involving temporary tables and transactions were introduced by a fix made in MySQL 5.1.37:
When a temporary table was created or dropped within a
transaction, any failed statement that following the
TEMPORARY TABLE or
TABLE statement triggered a rollback, which caused
the slave to diverge from the master.
TEMPORARY TABLE ... SELECT * FROM ... statement
was executed within a transaction in which only tables using
transactional storage engines were used and the transaction
was rolled back at the end, the changes—including the
creation of the temporary table—were not written to
the binary log.
The current fix restores the correct behavior in both of these cases. (Bug #53560)
References: This bug was introduced by Bug #43929.
CURRENT_USER was used to supply
the name and host of the affected user or of the definer in any
of the statements
ALTER EVENT, the reference to
CURRENT_USER was not expanded
when written to the binary log. This resulted in
CURRENT_USER being expanded to
the user and host of the slave SQL thread on the slave, thus
breaking replication. Now
CURRENT_USER are expanded prior
to being written to the binary log in such cases, so that the
correct user and host are referenced on both the master and the
Replication could break if a transaction involving both
transactional and nontransactional tables was rolled back to a
savepoint. It broke if a concurrent connection tried to drop a
transactional table which was locked after the savepoint was
DROP TABLE completed
SAVEPOINT was executed because the lock on the table
was dropped by the transaction. When the slave later tried to
apply the binary log events, it failed because the table had
already been dropped.
For the general query log and slow query log, logging to tables incurred excessive overhead beginning with MySQL 5.1.21. This overhead has been eliminated. (Bug #11747038, Bug #30414)
References: See also Bug #29129.
PERFORMANCE_SCHEMA database was not
correctly created and populated on Windows.
After an RPM installation, mysqld would be
started with the
root user, rather than the
When upgrading an existing install with an RPM on Linux, the
MySQL server might not have been restarted properly. This was
due to a naming conflict when upgrading from a
community named RPM. Previous installations
are now correctly removed, the MySQL initialization script is
recreated, and the MySQL server is restarted as normal.
CMake produced bad dependencies for the
sql/lex_hash.h file during configuration.
The default compiler options for Mac OS X 10.5 were set incorrectly. (Bug #55601)
The Windows MSI installer failed during installation to preserve custom settings, such as the configured data directory. (Bug #55169)
The optimization method of the
storage engine did not preserve the
file embedded in the
.ARZ file when
.ARZ file for optimization.
This meant an
ARCHIVE table that had been
optimized could not be discovered.
ARCHIVE engine stores the
.frm file in the
file so it can be transferred from machine to machine without
also needing to copy the
.frm file. The
engine subsequently restores the embedded
.frm during discovery.
-features=no%except option was missing from
the build for Solaris/x86.
Building MySQL on Solaris 8 x86 failed when using Sun Studio due to gcc inline assembly code. (Bug #55061)
The ABI check for MySQL failed to compile with gcc 4.5. (Bug #52514)
Builds of MySQL generated a large number of warnings. (Bug #53445)
mysql-debug.pdb supplied with releases
did not match the corresponding mysqld.exe.
ERROR 1168 (HY000): Unable to open underlying table which is differently defined or of non-MyISAM type or doesn't exist
An assertion occurred in
The problem was found while running RQG tests and the assertion
Performance Schema header files were not installed in the correct directory. (Bug #53255)
Attempts to access a nonexistent Performance Schema table resulted in a misleading error message. (Bug #52586)
The Performance Schema could enter an infinite loop if required to create a large number of mutex instances. (Bug #52502)
The server could crash when processing subqueries with empty results. (Bug #53236)
Missing Performance Schema tables were not reported in the error log at server startup. (Bug #53617)
PERFORMANCE_SCHEMA STATUS underreported the amount of
memory allocated by the Performance Schema.
A client with automatic reconnection enabled saw the error
Lost connection to MySQL server during
query if the connection was lost between the
mysql_stmt_execute() C API
mysql_stmt_errno() returned 0,
not the corresponding error number 2013.
A client could supply data in chunks to a prepared statement
parameter other than of type
BLOB using the
API function (or
command). This led to a crash because other data types are not
valid for long data.
The server failed to disregard sort order for some zero-length tuples, leading to an assertion failure. (Bug #54459)
If a session tried to drop a database containing a table opened
HANDLER in another session,
ALTER) executed by that session produced a
index_merge for join tables other than
the first table used excessive memory.
The results of some
ORDER BY ... DESC queries
were sorted incorrectly.
Index Merge between three indexes could
return incorrect results.
A signal-handler redefinition for
removed. The redefinition could cause the server to encounter a
kernel deadlock on Solaris when there are many active threads.
Other POSIX platforms might also be affected.
caused compilation problems in Windows. This was changed to
mysql_secure_installation did not properly
identify local accounts and could incorrectly remove nonlocal
In a slave SQL thread or Event Scheduler thread, the
SLEEP() function could not sleep
more than five seconds.
mysql_secure_installation sometimes failed to locate the mysql client. (Bug #52274)
If a symbolic link was used in a file path name, the Performance Schema did not resolve all file I/O events to the same name. (Bug #52134)
Performance Schema event collection for a thread could “leak” from one connection to another if the thread was used for one connection, then cached, then reused for another connection. (Bug #54782)
The Performance Schema displayed spurious startup error messages when the server was run in bootstrap mode. (Bug #54467)
Statements of the form
UPDATE ... WHERE ... ORDER
BY used a
filesort even when not
Prior to this fix, index hints were accepted for
UPDATE statements but were ignored. Now they
References: See also Bug #53737, Bug #53742.
The patch for Bug #36569 caused performance regressions and
incorrect execution of some
(Bug #53737, Bug #53742)
incorrect precision for
ucs2 data file with
INFILE was subject to three problems. 1) Incorrect
parsing of the file as
ucs2 data, resulting
in incorrect length of the parsed string. This is fixed by
truncating the invalid trailing bytes (incomplete multi-byte
characters) when reading from the file. 2) Reads from a proper
ucs2 file did not recognize newline
characters. This is fixed by first checking whether a byte is a
newline (or any other special character) before reading it as a
part of a multi-byte character. 3) When using user variables to
hold column data, the character set of the user variable was set
incorrectly to the database charset. This is fixed by setting it
to the character set specified in the
INFILE statement, if any.
Incorrect error handling could result in an
OPTIMIZE TABLE crash.
to a nonzero value, searches for table or database names in
INFORMATION_SCHEMA tables could produce
In debug builds, an assertion could be raised when the server
tried to send an OK packet to the client after having failed to
detect errors during processing of the
condition of an
Some queries involving
GROUP BY and a
function that returned
raised a debug assertion.
sql_select_limit = 0 did not work.
mysql_upgrade could incorrectly remove
safemalloc was excessively slow under certain
conditions and has been removed. The
--skip-safemalloc server option
has also been removed, and the
--with-debug=full configuration option is no
Queries that named view columns in a
clause could cause a server crash.
Portability problems in
STATUS could lead to incorrect results on some
A debugging assertion could be raised after a write failure to a closed socket. (Bug #42496)
INFORMATION_SCHEMA tables for
rows matching a nonexistent database produced an error instead
of an empty query result.
GROUP BY operations used
functions returned badly formed maximum strings for Asian
character sets, which caused problems for storage engines.
Rows inserted in a table by one session were not immediately visible to another session that queried the table, even if the insert had committed. (Bug #37521)
mysqld_safe contained a syntax error that prevented it from restarting the server. (Bug #54991)
MERGE storage engine tried to
use memory mapping on the underlying
MyISAM tables even on platforms
that do not support it and even when
myisam_use_mmap was disabled.
This led to a hang for
INSERT INTO ...
SELECT FROM statements that selected from a
MyISAM table into a
MERGE table that contained the same
(Bug #54811, Bug #50788)
DROP DATABASE failed if there was
TEMPORARY table with the same name as a
TEMPORARY table in the database.
SHOW CREATE TRIGGER took a
stronger metadata lock than required. This caused the statement
to be blocked unnecessarily. For example,
LOCK TABLES ...
WRITE in one session blocked
CREATE TRIGGER in another session.
SHOW CREATE TRIGGER
statement issued inside a transaction did not release its
metadata locks at the end of statement execution. Consequently,
SHOW CREATE TRIGGER was able to
block other sessions from accessing the table (for example,
SHOW CREATE TABLE statement
issued inside a transaction did not release its metadata locks
at the end of statement execution. Consequently,
SHOW CREATE TABLE was able to
block other sessions from accessing the table (for example,
XA START had a
race condition that could cause a server crash.
DELETE ordered by
a column that had a hash-type index could raise an assertion or
cause a server crash.
Errors during processing of
READ statements were not detected, so the handler code
still tried to send EOF to the client, raising an assertion.
A statement that was aborted by
KILL QUERY while
it waited on a metadata lock could raise an assertion in debug
builds, or send OK to the client instead of
ER_QUERY_INTERRUPTED in regular
mysql_upgrade did not handle the
--ssl option properly.
Enumeration plugin variables were subject to a type-casting error, causing inconsistent results between different platforms. (Bug #42144)
INTO ... SELECT statements could raise a debug
The server was not checking for errors generated during the
Item::val_xxx() methods when
copying data to a group, order, or distinct temp table's row.
ORDER BY clauses that included user-variable
expressions could raise a debug assertion.
For distributions built with CMake rather
than the GNU autotools, mysql lacked
pager support, and some scripts were built
without the execute bit set.
(Bug #54466, Bug #54129)
variable was unavailable on non-Solaris systems.
If audit plugins were installed that were interested in
MYSQL_AUDIT_GENERAL_CLASS events and the
general query log was disabled, failed
INSTALL PLUGIN or
UNINSTALL PLUGIN statements
caused a server crash.
Incorrect handling of user variable assignments as subexpressions could lead to incorrect results or server crashes. (Bug #55615)
PARTITION BY KEY on a
column raised a debugging assertion.
(Bug #52121, Bug #11759782)
CREATE TABLE t1 AS SELECT HEX() ... caused a
This bug fix involved several changes to the states displayed by
Table lock was replaced with
Waiting for table level lock.
Waiting for table was replaced with
Waiting for table flush.
These states are new:
Waiting for global metadata
Waiting for schema metadata
Waiting for stored function
Waiting for stored
procedure metadata lock,
table metadata lock.
statement unnecessarily aborted transactions.
tbl_list WITH READ LOCK
IF() with a subquery argument
could raise a debug assertion for debug builds under some
DELAYED statements were not detected. The server could
crash if the delayed handler thread was killed due to a
conflicting shared metadata lock.
Some functions did not calculate their
max_length metadata value correctly.
The embedded server raised an assertion when it attempted to load plugins. (Bug #56085)
FORMAT() did not respect the
decimal point character if the locale was changed and always
returned an ASCII value.
DROP TABLE held a lock during
unlink() file system operations, causing
performance problems if
unlink() took a long
A join with an aggregated function and impossible
WHERE condition returned an extra row.
Threads that were calculating the estimated number of records
for a range scan did not respond to the
KILL statement. That is, if a
range join type is possible
(even if not selected by the optimizer as a join type of choice
and thus not shown by
the query in the
statistics state (shown by
SHOW PROCESSLIST) did not
respond to the
Problems in the atomic operations implementation could lead to server crashes. (Bug #22320, Bug #52261)