|| ||Joerg Bruehe <joerg-AT-mysql.com>|
|| ||announce-AT-lists.mysql.com, mysql-AT-lists.mysql.com, packagers-AT-lists.mysql.com|
|| ||MySQL 5.1.23-rc has been released (part 1)|
|| ||Wed, 13 Feb 2008 23:24:52 +0100|
Dear MySQL users,
We are proud to present to you the MySQL Server 5.1.23-rc release,
a new "release candidate" version of the popular open source database.
Bear in mind that this is still a "candidate" release, and as with any
other pre-production release, caution should be taken when installing on
production level systems or systems with critical data. For production
level systems using 5.0, we would like to direct your attention to the
product description of MySQL Enterprise at:
The MySQL 5.1.23-rc release is now available in source and binary form
for a number of platforms from our download pages at
and mirror sites. Note that not all mirror sites may be up to date at
this point in time, so if you can't find this version on some mirror,
please try again later or choose another download site.
Please also note that some of our mirrors are currently experiencing
problems that may result in serving corrupted files. We are working with
the mirror maintainers to resolve this.
We welcome and appreciate your feedback, bug reports, bug fixes,
The description of the changes from version 5.1.22-rc to this 5.1.23-rc
is some 1,800 lines long, that is about 96 kB. As some mail systems are
bound to truncate long mail at 64 kB, I split the announcement into two
parts - this is part 1 only.
The following section lists the (first part of the) changes from version
to version in the MySQL source code since the latest released version of
MySQL 5.1, the MySQL 5.1.22-rc release. It can also be viewed online at
Functionality added or changed:
* Important Change: Partitioning: Security Fix: It was
possible, by creating a partitioned table using the DATA
DIRECTORY and INDEX DIRECTORY options to gain privileges
on other tables having the same name as the partitioned
table. As a result of this fix, any table-level DATA
DIRECTORY or INDEX DIRECTORY options are now ignored for
(Bug#32091: http://bugs.mysql.com/32091, CVE-2007-5970
See also Bug#29325: http://bugs.mysql.com/29325,
* Incompatible Change: In MySQL 5.1.6, when log tables were
implemented, the default log destination for the general
query and slow query log was TABLE. This default has been
changed to FILE, which is compatible with MySQL 5.0, but
incompatible with earlier releases of MySQL 5.1 from
5.1.6 to 5.1.20. If you are upgrading from MySQL 5.0 to
this release, no logging option changes should be
necessary. However, if you are upgrading from 5.1.6
through 5.1.20 to this release and were using TABLE
logging, use the --log-output=TABLE option explicitly to
preserve your server's table-logging behavior.
In MySQL 5.1.x, this bug was addressed twice because it
turned out that the default was set in two places, only
one of which was fixed the first time.
* Incompatible Change
The parser accepted statements that contained /* ... */
that were not properly closed with */, such as SELECT 1
/* + 2. Statements that contain unclosed /*-comments now
are rejected with a syntax error.
This fix has the potential to cause incompatibilities.
Because of Bug#26302: http://bugs.mysql.com/26302, which
caused the trailing */ to be truncated from comments in
views, stored routines, triggers, and events, it is
possible that objects of those types may have been stored
with definitions that now will be rejected as
syntactically invalid. Such objects should be dropped and
re-created so that their definitions do not contain
* MySQL Cluster: The following improvements have been made
in the ndb_size.pl utility:
+ The script can now be used with multiple databases;
lists of databases and tables can also be excluded
+ Schema name information has been added to index
+ The database name is now an optional parameter, the
exclusion of which causes all databases to be
+ If selecting from INFORMATION_SCHEMA fails, the
script now attempts to fall back to SHOW TABLES.
+ A --real_table_name option has been added; this
designates a table to handle unique index size
+ The report title has been amended to cover cases
where more than one database is being analyzed.
Support for a --socket option was also added.
For more information, see Section 15.9.15, "ndb_size.pl
--- NDBCluster Size Requirement Estimator."
* MySQL Cluster: Mapping of NDB error codes to MySQL
storage engine error codes has been improved.
* MySQL Cluster: The output from the cluster management
client showing the progress of data node starts has been
improved. (Bug#23354: http://bugs.mysql.com/23354)
* Partitioning: Error messages for partitioning syntax
errors have been made more descriptive.
* Replication: Replication of the following now switches to
row-based logging in MIXED mode, and generates a warning
in STATEMENT mode:
See Section 18.104.22.168, "Mixed Binary Logging (MBL) Format,"
for more information.
* mysqltest now has a change_user command to change the
user for the current connection. (It invokes the
mysql_change_user() C API function.)
* mysql-test-run.pl now allows a suite name prefix to be
specified in command-line arguments that name test cases.
The test name syntax now is
[suite_name.]test_name[.suffix]. For example,
mysql-test-run.pl binlog.mytest runs the mytest.test test
in the binlog test suite.
* The --event-scheduler option without a value disabled the
event scheduler. Now it enables the event scheduler.
* mysqldump produces a -- Dump completed on DATE comment at
the end of the dump if --comments is given. The date
causes dump files for identical data take at different
times to appear to be different. The new options
--dump-date and --skip-dump-date control whether the date
is added to the comment. --skip-dump-date suppresses date
printing. The default is --dump-date (include the date in
the comment). (Bug#31077: http://bugs.mysql.com/31077)
* Server parser performance was improved for expression
parsing by lowering the number of state transitions and
* Server parser performance was improved for identifier
lists, expression lists, and UDF expression lists.
* Server parser performance was improved for boolean
expressions. (Bug#30237: http://bugs.mysql.com/30237)
* The LAST_EXECUTED column of the INFORMATION_SCHEMA.EVENTS
table now indicates when the event started executing
rather than when it finished executing. As a result, the
ENDS column is never less than LAST_EXECUTED.
* The mysql_odbc_escape_string() C API function has been
removed. It has multi-byte character escaping issues,
doesn't honor the NO_BACKSLASH_ESCAPES SQL mode and is
not needed anymore by Connector/ODBC as of 3.51.17.
* If a MyISAM table is created with no DATA DIRECTORY
option, the .MYD file is created in the database
directory. By default, if MyISAM finds an existing .MYD
file in this case, it overwrites it. The same applies to
.MYI files for tables created with no INDEX DIRECTORY
option. To suppress this behavior, start the server with
the new --keep_files_on_create option, in which case
MyISAM will not overwrite existing files and returns an
error instead. (Bug#29325: http://bugs.mysql.com/29325)
* The default value of the connect_timeout system variable
was increased from 5 to 10 seconds. This might help in
cases where clients frequently encounter errors of the
form Lost connection to MySQL server at 'XXX', system
error: errno. (Bug#28359: http://bugs.mysql.com/28359)
* MySQL now can be compiled with gcc 4.2.x. There was a
problem involving a conflict with the min() and max()
macros in my_global.h.
* Security Fix: Replication: It was possible for any
connected user to issue a BINLOG statement, which could
be used to escalate privileges.
Use of the BINLOG statement now requires the SUPER
privilege. (Bug#31611: http://bugs.mysql.com/31611,
* Security Fix: Three vulnerabilities in yaSSL versions
1.7.5 and earlier were discovered that could lead to a
server crash or execution of unauthorized code. The
exploit requires a server with yaSSL enabled and TCP/IP
connections enabled, but does not require valid MySQL
account credentials. The exploit does not apply to
The proof-of-concept exploit is freely available on the
Internet. Everyone with a vulnerable MySQL configuration
is advised to upgrade immediately.
(Bug#33814: http://bugs.mysql.com/33814, CVE-2008-0226
* Security Fix: Using RENAME TABLE against a table with
explicit DATA DIRECTORY and INDEX DIRECTORY options can
be used to overwrite system table information by
replacing the symbolic link points. the file to which the
MySQL will now return an error when the file to which the
symlink points already exists.
(Bug#32111: http://bugs.mysql.com/32111, CVE-2007-5969
* Security Fix: ALTER VIEW retained the original DEFINER
value, even when altered by another user, which could
allow that user to gain the access rights of the view.
Now ALTER VIEW is allowed only to the original definer or
users with the SUPER privilege.
* Security Fix: When using a FEDERATED table, the local
server could be forced to crash if the remote server
returned a result with fewer columns than expected.
* Security Enhancement: It was possible to force an error
message of excessive length which could lead to a buffer
overflow. This has been made no longer possible as a
* Important Change: Incompatible Change: A number of
problems existed in the implementation of MERGE tables
that could cause problems. The problems are summarized
+ Bug#26379: http://bugs.mysql.com/26379 - Combination
of FLUSH TABLE and REPAIR TABLE corrupts a MERGE
table. This was caused in a number of situations:
1. A thread trying to lock a MERGE table performs
busy waiting while REPAIR TABLE or a similar
table administration task is ongoing on one or
more of its MyISAM tables.
2. A thread trying to lock a MERGE table performs
busy waiting until all threads that did REPAIR
TABLE or similar table administration tasks on
one or more of its MyISAM tables in LOCK TABLES
segments do UNLOCK TABLES. The difference
against problem #1 is that the busy waiting
takes place after the administration task. It
is terminated by UNLOCK TABLES only.
3. Two FLUSH TABLES within a LOCK TABLES segment
can invalidate the lock. This does not require
a MERGE table. The first FLUSH TABLES can be
replaced by any statement that requires other
threads to reopen the table. In 5.0 and 5.1 a
single FLUSH TABLES can provoke the problem.
+ Bug#26867: http://bugs.mysql.com/26867 -
Simultaneously executing LOCK TABLES and REPAIR
TABLE on a MERGE table would result in memory/cpu
Trying DML on a MERGE table, which has a child
locked and repaired by another thread, made an
infinite loop in the server.
+ Bug#26377: http://bugs.mysql.com/26377 - Deadlock
with MERGE and FLUSH TABLE
Locking a MERGE table and its children in
parent-child order and flushing the child deadlocked
+ Bug#25038: http://bugs.mysql.com/25038 - Waiting
Truncating a MERGE child, while the MERGE table was
in use, let the truncate fail instead of waiting for
the table to become free.
+ Bug#25700: http://bugs.mysql.com/25700 - MERGE base
tables get corrupted by OPTIMIZE/ANALYZE/REPAIR
Repairing a child of an open MERGE table corrupted
the child. It was necessary to FLUSH the child
+ Bug#30275: http://bugs.mysql.com/30275 - MERGE
tables: FLUSH TABLES or UNLOCK TABLES causes server
Flushing and optimizing locked MERGE children
crashed the server.
+ Bug#19627: http://bugs.mysql.com/19627 - temporary
merge table locking
Use of a temporary MERGE table with non-temporary
children could corrupt the children.
Temporary tables are never locked. Creation of
tables with non-temporary children of a temporary
MERGE table is now prohibited.
+ Bug#27660: http://bugs.mysql.com/27660 - Falcon:
MERGE table possible
It was possible to create a MERGE table with
+ Bug#30273: http://bugs.mysql.com/30273 - MERGE
tables: Can't lock file (errno: 155)
This was a Windows-only bug. Table administration
statements sometimes failed with "Can't lock file
The fix introduces the following changes in behavior:
+ This patch changes the behavior of temporary MERGE
tables. Temporary MERGE must have temporary
children. The old behavior was wrong. A temporary
table is not locked. Hence even non-temporary
children were not locked. See
+ You cannot change the union list of a non-temporary
MERGE table when LOCK TABLES is in effect. The
following does not work:
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ...;
LOCK TABLES t1 WRITE, t2 WRITE, m1 WRITE;
ALTER TABLE m1 ... UNION=(t1,t2) ...;
However, you can do this with a temporary MERGE
+ You cannot create a MERGE table with CREATE ...
SELECT, neither as a temporary MERGE table, nor as a
non-temporary MERGE table. For example:
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...;
gives error message: table is not BASE TABLE.
* Incompatible Change: It is no longer possible to create
CSV tables with NULL columns. However, for backwards
compatibility, you can continue to use such tables that
were created in previous MySQL releases.
* Incompatible Change: Inserting a row with a NULL value
for a DATETIME column results in a CSV file that the
storage engine cannot read.
All CSV tables now need to be defined with each column
marked as NOT NULL. An error is raised if you try to
create a CSV table with columns that are not defined with
NOT NULL. (Bug#31473: http://bugs.mysql.com/31473,
* Incompatible Change: SET PASSWORD statements now cause an
implicit commit, and thus are prohibited within stored
functions and triggers.
* Incompatible Change: The mysql_install_db script could
fail to locate some components (including resolveip)
during execution if the --basedir option was specified on
the command-line or within the my.cnf file. This was due
to a conflict when comparing the compiled-in values and
the supplied values.
The --source-install command-line option to the script
has been removed and replaced with the --srcdir option.
mysql_install_db now locates components either using the
compiled-in options, the --basedir option or --srcdir
option. (Bug#30759: http://bugs.mysql.com/30759)
* Incompatible Change: Within a stored routine, it is no
longer allowable to declare a cursor for a SHOW
statement. This happened to work in some instances, but
is no longer supported.
* Incompatible Change: GRANT and REVOKE statements now
cause an implicit commit, and thus are prohibited within
stored functions and triggers.
* Incompatible Change: It was possible for option files to
be read twice at program startup, if some of the standard
option file locations turned out to be the same
directory. Now duplicates are removed from the list of
files to be read.
Also, users could not override system-wide settings using
~/.my.cnf because SYSCONFDIR/my.cnf was read last. The
latter file now is read earlier so that ~/.my.cnf can
override system-wide settings.
* Important Change: MySQL Cluster: AUTO_INCREMENT columns
had the following problems when used in NDB tables:
+ The AUTO_INCREMENT counter was not updated correctly
when such a column was updated.
+ AUTO_INCREMENT values were not prefetched beyond
+ AUTO_INCREMENT values were not handled correctly
with INSERT IGNORE statements.
+ After being set, ndb_autoincrement_prefetch_sz
showed a value of 1, regardless of the value it had
actually been set to.
As part of this fix, the behavior of
ndb_autoincrement_prefetch_sz has changed. Setting this
to less than 32 no longer has any effect on prefetching
within statements (where IDs are now always obtained in
batches of 32 or more), but only between statements. The
default value for this variable has also changed, and is
now 1. (Bug#25176: http://bugs.mysql.com/25176,
* Partitioning: Important Note: An apostrophe or single
quote character (') used in the DATA DIRECTORY, INDEX
DIRECTORY, or COMMENT for a PARTITION clause caused the
server to crash. When used as part of a CREATE TABLE
statement, the crash was immediate. When used in an ALTER
TABLE statement, the crash did not occur until trying to
perform a SELECT or DML statement on the table. In either
case, the server could not be completely restarted until
the .FRM file corresponding to the newly created or
altered table was deleted.
Upgrading to the current (or later) release solves this
problem only for tables that are newly created or
altered. Tables created or altered in previous versions
of the server to include ' characters in PARTITION
options must still be removed by deleting the
corresponding .FRM files and re-creating them afterwards.
* Important Note: The RENAME DATABASE statement was removed
and replaced with ALTER DATABASE db_name UPGRADE DATA
DIRECTORY NAME. The RENAME DATABASE statement was
intended for upgrading database directory names to the
encoding format used in 5.1 for representing identifiers
in the filesystem (see Section 7.2.3, "Mapping of
Identifiers to Filenames"). However, the statement was
found to be dangerous because it could result in loss of
database contents. See Section 11.1.18, "RENAME DATABASE
Syntax" and Section 11.1.1, "ALTER DATABASE Syntax."
* Replication: MySQL Cluster: Row-based replication from or
to a big-endian machine where the table used the NDB
storage engine failed, if the same table on the other
machine was either non-NDB or the other machine was
little-endian. (Bug#29549: http://bugs.mysql.com/29549,
See also Bug#24231: http://bugs.mysql.com/24231,
* MySQL Cluster: An improperly reset internal signal was
observed as a hang when using events in the NDB API but
could result in various errors.
* MySQL Cluster: Incorrectly handled parameters could lead
to a crash in the Transaction Coordinator during a node
failure, causing other data nodes to fail.
* MySQL Cluster: A memory leak occurred if a subscription
start request was received by the subscription manager
before the node making the request was fully connected to
the cluster. (Bug#32652: http://bugs.mysql.com/32652)
* MySQL Cluster: A local checkpoint could sometimes be
started before the previous LCP was restorable from a
* MySQL Cluster: High numbers of API nodes on a slow or
congested network could cause connection negotiation to
time out prematurely, leading to the following issues:
+ Excessive retries
+ Excessive CPU usage
+ Partially connected API nodes
* MySQL Cluster: The failure of a master node could lead to
subsequent failures in local checkpointing.
* MySQL Cluster: An error with an if statement in
sql/ha_ndbcluster.cc could potentially lead to an
infinite loop in case of failure when working with
AUTO_INCREMENT columns in NDB tables.
* MySQL Cluster: The NDB storage engine code was not safe
for strict-alias optimization in gcc 4.2.1.
* MySQL Cluster: It was possible in some cases for a node
group to be "lost" due to missed local checkpoints
following a system restart.
* MySQL Cluster: A query against a table with TEXT or BLOB
columns that would return more than a certain amount of
data failed with Got error 4350 'Transaction already
aborted' from NDBCLUSTER.
This regression was introduced by
* MySQL Cluster: NDB tables having names containing
non-alphanumeric characters (such as " $ ") were not
* MySQL Cluster: A node failure during a local checkpoint
could lead to a subsequent failure of the cluster during
a system restart.
* MySQL Cluster: When handling BLOB columns, the addition
of read locks to the lock queue was not handled
correctly. (Bug#30764: http://bugs.mysql.com/30764)
* MySQL Cluster: Discovery of NDB tables did not work
correctly with INFORMATION_SCHEMA.
* MySQL Cluster: A filesystem close operation could fail
during a node or system restart.
* MySQL Cluster: Transaction timeouts were not handled well
in some circumstances, leading to excessive number of
transactions being aborted unnecessarily.
* MySQL Cluster: The cluster management client could not
connect, and would hang instead. This issue affected Mac
OS X 64-bit only.
* MySQL Cluster: Attempting to restore a backup made on a
cluster host using one endian to a machine using the
other endian could cause the cluster to fail.
* MySQL Cluster: Log event requests to ndb_mgmd could time
out, causing it to fail.
* MySQL Cluster: In some cases, the cluster managment
server logged entries multiple times following a restart
of mgmd. (Bug#29565: http://bugs.mysql.com/29565)
* MySQL Cluster: ndb_mgm --help did not display any
information about the -a option.
* MySQL Cluster: An interpreted program of sufficient size
and complexity could cause all cluster data nodes to shut
down due to buffer overruns.
* MySQL Cluster: ndb_size.pl failed on tables with FLOAT
columns whose definitions included commas (for example,
FLOAT(6,2)). (Bug#29228: http://bugs.mysql.com/29228)
* MySQL Cluster: The error message for NDB error code 275
(Out of transaction records for complete phase) was
missing. (Bug#29139: http://bugs.mysql.com/29139)
* MySQL Cluster: Reads on BLOB columns were not locked when
they needed to be to guarantee consistency.
See also Bug#31482: http://bugs.mysql.com/31482
* MySQL Cluster: A query using joins between several large
tables and requiring unique index lookups failed to
complete, eventually returning Uknown Error after a very
long period of time. This occurred due to inadequate
handling of instances where the Transaction Coordinator
ran out of TransactionBufferMemory, when the cluster
should have returned NDB error code 4012 (Request ndbd
time-out). (Bug#28804: http://bugs.mysql.com/28804)
* MySQL Cluster: There was a short interval during the
startup process prior to the beginning of heartbeat
detection such that, were an API or management node to
reboot or a network failure to occur, data nodes could
not detect this, with the result that there could be a
* MySQL Cluster: The description of the --print option
provided in the output from ndb_restore --help was
incorrect. (Bug#27683: http://bugs.mysql.com/27683)
* MySQL Cluster: Restoring a backup made on a cluster host
using one endian to a machine using the other endian
failed for BLOB and DATETIME columns.
* MySQL Cluster: An invalid subselect on an NDB table could
cause mysqld to crash.
* MySQL Cluster: An attempt to perform a SELECT ... FROM
INFORMATION_SCHEMA.TABLES whose result included
information about NDB tables for which the user had no
privileges crashed the MySQL Server on which the query
was performed. (Bug#26793: http://bugs.mysql.com/26793)
* MySQL Cluster: Performing DELETE operations after a data
node had been shut down could lead to inconsistent data
following a restart of the node.
* MySQL Cluster: UPDATE IGNORE could sometimes fail on NDB
tables due to the use of unitialized data when checking
for duplicate keys to be ignored.
* MySQL Cluster: The cluster log was formatted
inconsistently and contained extraneous newline
characters. (Bug#25064: http://bugs.mysql.com/25064)
* MySQL Cluster: A restart of the cluster failed when more
than 1 REDO phase was in use.
* MySQL Cluster: When inserting a row into an NDB table
with a duplicate value for a non-primary unique key, the
error issued would reference the wrong key.
This improves on an initial fix for this issue made in
MySQL 5.1.13. (Bug#21072: http://bugs.mysql.com/21072)
* MySQL Cluster: An insufficiently descriptive and
potentially misleading Error 4006 (Connect failure - out
of connection objects...) was produced when either of the
following two conditions occurred:
1. There were no more transaction records in the
2. an Ndb object in the NDB API was initialized with
Separate error messages are now generated for each of
these two cases. (Bug#11313: http://bugs.mysql.com/11313)
* Partitioning: Replication: Replication of partitioned
tables using the InnoDB storage engine failed with
binlog-format=ROW or binlog-format=MIXED.
* Partitioning: It was possible to partition a table to
which a foreign key referred.
* Partitioning: A query of the form SELECT col1 FROM table
GROUP BY (SELECT col2 FROM table LIMIT 1); against a
partitioned table having a SET column crashed the server.
* Partitioning: SHOW CREATE TABLE misreported the value of
AUTO_INCREMENT for partitioned tables using either of the
InnoDB or ARCHIVE storage engines.
* Partitioning: Selecting from
INFORMATION_SCHEMA.PARTITIONS while partition management
statements (for example, ALTER TABLE ... ADD PARTITION)
were executing caused the server to crash.
* Partitioning: An error in the internal function
mysql_unpack_partition() led to a fatal error in
subsequent calls to open_table_from_share().
* Partitioning: Repeated updates of a table that was
partitioned by KEY on a TIMESTAMP column eventually
crashed the server.
* Partitioning: Changing the storage engine used by a table
having subpartitions led to a server crash.
* Partitioning: ORDER BY ... DESC did not always work
correctly when selecting from partitioned tables.
See also Bug#31001: http://bugs.mysql.com/31001
* Partitioning: Selecting from a table partitioned by KEY
on a VARCHAR column whose size was greater than 65530
caused the server to crash.
* Partitioning: INSERT DELAYED into a partitioned table
crashed the server.
* Partitioning: Using ALTER TABLE to partition an existing
table having an AUTO_INCREMENT column could crash the
server. (Bug#30878: http://bugs.mysql.com/30878)
This regression was introduced by
* Partitioning: ALTER TABLE ... COALESCE PARTITION on a
table partitioned by [LINEAR] HASH or [LINEAR] KEY caused
the server to crash.
* Partitioning: LIKE queries on tables partitioned by KEY
and using third-party storage engines could return
See also Bug#29320: http://bugs.mysql.com/29320,
* Partitioning: It was not possible to insert the greatest
possible value for a given data type into a partitioned
table. For example, consider a table defined as shown
CREATE TABLE t (c BIGINT UNSIGNED)
PARTITION BY RANGE(c) (
PARTITION p0 VALUES LESS THAN MAXVALUE
The largest possible value for a BIGINT UNSIGNED column
is 18446744073709551615, but the statement INSERT INTO t
VALUES (18446744073709551615); would fail, even though
the same statement succeeded were t not a partitioned
In other words, MAXVALUE was treated as being equal to
the greatest possible value, rather than as a least upper
bound. (Bug#29258: http://bugs.mysql.com/29258)
* Replication: When dropping a database containing a stored
procedure while using row-cased replication, the delete
of the stored procedure from the mysql.proc table was
recorded in the binary log following the DROP DATABASE
statement. To correct this issue, DROP DATABASE now uses
* Replication: It was possible for the name of the relay
log file to exceed the amount of memory reserved for it,
possibly leading to a crash of the server.
See also Bug#28597: http://bugs.mysql.com/28597
* Replication: Corruption of log events caused the server
to crash on 64-bit Linux systems having 4 GB of memory or
more. (Bug#31793: http://bugs.mysql.com/31793)
* Replication: Trying to replicate an update of a row that
was missing on the slave led to a failure on the slave.
* Replication: Table names were displayed as binary
"garbage" characters in slave error messages. The issue
was observed on 64-bit Windows but may have effected
other platforms. (Bug#30854: http://bugs.mysql.com/30854)
* Replication: One thread could read uninitialized memory
from the stack of another thread. This issue was only
known to occur in a mysqld process acting as both a
master and a slave.
* Replication: It was possible to set
SQL_SLAVE_SKIP_COUNTER such that the slave would jump
into the middle of a transaction. This fix improves on
one made for this bug in MySQL 5.1.20; the previous fix
insured that the slave could not be made to jump into the
middle of an event group, but the slave failed to
recognize that BEGIN, COMMIT, and ROLLBACK statements
could begin or end an event group.
See also Bug#12691: http://bugs.mysql.com/12691
* Replication: Due a previous change in how the default
name and location of the binlog file were determined,
replication failed following some upgrades.
See also Bug#31836: http://bugs.mysql.com/31836
This regression was introduced by
* Replication: Stored procedures having BIT parameters were
not replicated correctly.
* Replication: Issuing SHOW SLAVE STATUS as mysqld was
shutting down could cause a crash.
* Replication: If a temporary error occured inside an event
group on an event that was not the first event of the
group, the slave could get caught in an endless loop
because the retry counter was reset whenever an event was
See also Bug#12691: http://bugs.mysql.com/12691,
* Replication: An UPDATE statement using a stored function
that modified a non-transactional table was not logged if
it failed. This caused the copy of the non-transactional
table on the master have a row that the copy on the slave
did not. (Bug#23333: http://bugs.mysql.com/23333)
See also Bug#12713: http://bugs.mysql.com/12713
* Replication: A replication slave sometimes failed to
reconnect because it was unable to run SHOW SLAVE HOSTS.
It was not necessary to run this statement on slaves
(since the master should track connection IDs), and the
execution of this statement by slaves was removed.
See also Bug#13963: http://bugs.mysql.com/13963,
* Replication: A replication slave sometimes stopped for
changes that were idempotent (that is, such changes
should have been considered "safe"), even though it
should have simply noted that the change was already
done, and continued operation.
* Cluster Replication: A replication slave could return
"garbage" data that was not in recognizable row format
due to a problem with the internal all_set() method.
* Cluster Replication: Memory was mistakenly freed for
NdbBlob objects when adding an index while replicating
the cluster, which could cause mysqld to crash.
See also Bug#18106: http://bugs.mysql.com/18106
* Cluster Replication: Under certain conditions, the slave
stopped processing relay logs. This resulted in the logs
never being cleared and the slave eventually running out
of disk space. (Bug#31958: http://bugs.mysql.com/31958)
* Cluster Replication: A node failure during replication
could lead to buckets out of order; now active
subscribers are checked for, rather than empty buckets.
* Cluster Replication: When the master mysqld crashed or
was restarted, no LOST_EVENTS entry was made in the
binlog. (Bug#31484: http://bugs.mysql.com/31484)
See also Bug#21494: http://bugs.mysql.com/21494
* Cluster Replication: Incorrect handling of INSERT plus
DELETE operations with regard to local checkpoints caused
data node failures in multi-master replication setups.
* Cluster Replication: An issue with the
mysql.ndb_apply_status table could cause NDB schema
autodiscovery to fail in certain rare circumstances.
* Cluster API: A call to CHECK_TIMEDOUT_RET() in mgmapi.cpp
should have been a call to DBUG_CHECK_TIMEDOUT_RET().
* Cluster API: An Ndb object in the NDB API was initialized
with insufficient parallellism
* API: When the language option was not set correctly, API
programs calling mysql_server_init() crashed. This issue
was observed only on Windows platforms.
* Corrected a typecast involving bool on Mac OS X 10.5
(Leopard), which evaluated differently from earlier Mac
OS X versions. (Bug#38217: http://bugs.mysql.com/38217)
* Use of uninitialized memory for filesort in a subquery
caused a server crash.
* CREATE TABLE ... SELECT created tables that for date
columns used the obsolete Field_date type instead of
Field_newdate. (Bug#33256: http://bugs.mysql.com/33256)
* The fix for Bug#11230: http://bugs.mysql.com/11230 and
Bug#26215: http://bugs.mysql.com/26215 introduced a
significant input-parsing slowdown for the mysql client.
This has been corrected.
* The correct data type for a NULL column resulting from a
UNION could be determined incorrectly in some cases: 1)
Not correctly inferred as NULL depending on the number of
selects; 2) Not inferred correctly as NULL if one select
used a subquery. (Bug#32848: http://bugs.mysql.com/32848)
* For queries containing GROUP_CONCAT(DISTINCT col_list
ORDER BY col_list), there was a limitation that the
DISTINCT columns had to be the same as ORDER BY columns.
Incorrect results could be returned if this was not true.
* SHOW EVENTS and selecting from the
INFORMATION_SCHEMA.EVENTS table failed if the current
database was INFORMATION_SCHEMA.
* Use of the cp932 character set with CAST() in an ORDER BY
clause could cause a server crash.
* A subquery using an IS NULL check of a column defined as
NOT NULL in a table used in the FROM clause of the outer
query produced an invalid result.
* Specifying a non-existent column for an INSERT DELAYED
statement caused a server crash rather than producing an
error. (Bug#32676: http://bugs.mysql.com/32676)
* Use of CLIENT_MULTI_QUERIES caused libmysqld to crash.
* The INTERVAL() function incorrectly handled NULL values
in the value list.
* "GROUP BY expression WITH ROLLUP" could cause a server
crash, if "expression" was the constant "NULL" or evaluated
to NULL. (Bug#31095: http://bugs.mysql.com/31095,
* ORDER BY UpdateXML(...) caused the server to crash in
queries where UpdateXML() returned NULL.
* A SELECT ... GROUP BY bit_column query failed with an
assertion if the length of the BIT column used for the
GROUP BY was not an integer multiple of 8.
* Using SELECT INTO OUTFILE with 8-bit ENCLOSED BY
characters led to corrupted data when the data was
reloaded using LOAD DATA INFILE. This was because SELECT
INTO OUTFILE failed to escape the 8-bit characters.
* For FLUSH TABLES WITH READ LOCK, the server failed to
properly detect write-locked tables when running with
low-priority updates, resulting in a crash or deadlock.
* The rules for valid column names were being applied
differently for base tables and views.
* A query of the form SELECT @user_variable := constant AS
alias FROM table GROUP BY alias WITH ROLLUP crashed the
server. (Bug#32482: http://bugs.mysql.com/32482)
* Sending several KILL QUERY statements to target a
connection running SELECT SLEEP() could freeze the
server. (Bug#32436: http://bugs.mysql.com/32436)
* ssl-cipher values in option files were not being read by
libmysqlclient. (Bug#32429: http://bugs.mysql.com/32429)
* Repeated execution of a query containing a CASE
expression and numerous AND and OR relations could crash
the server. The root cause of the issue was determined to
be that the internal SEL_ARG structure was not properly
initialized when created.
* Referencing within a subquery an alias used in the SELECT
list of the outer query was incorrectly permitted.
* If a global read lock acquired with FLUSH TABLES WITH
READ LOCK was in effect, executing ALTER TABLE could
cause a server crash.
* An ORDER BY query on a view created using a FEDERATED
table as a base table caused the server to crash.
* Comparison of a BIGINT NOT NULL column with a constant
arithmetic expression that evaluated to NULL mistakenly
caused the error Column '...' cannot be null (error
1048). (Bug#32335: http://bugs.mysql.com/32335)
* Assigning a 65,536-byte string to a TEXT column (which
can hold a maximum of 65,535 bytes) resulted in
truncation without a warning. Now a truncation warning is
generated. (Bug#32282: http://bugs.mysql.com/32282)
* MIN() and MAX() could return incorrect results when an
index was present if a loose index scan was used.
* Some uses of user variables in a query could result in a
server crash. (Bug#32260: http://bugs.mysql.com/32260)
* Memory corruption could occur due to large index map in
Range checked for each record status reported by EXPLAIN
SELECT. The problem was based in an incorrectly
calculated length of the buffer used to store a
hexadecimal representation of an index map, which could
result in buffer overrun and stack corruption under some
circumstances. (Bug#32241: http://bugs.mysql.com/32241)
* Various test program cleanups were made: 1) mytest and
libmysqltest were removed. 2) bug25714 displays an error
message when invoked with incorrect arguments or the
--help option. 3) mysql_client_test exits cleanly with a
proper error status.
* The default grant tables on Windows contained information
for host production.mysql.com, which should not be there.
* Under certain conditions, the presence of a GROUP BY
clause could cause an ORDER BY clause to be ignored.
* For comparisons of the form date_col OP datetime_const
(where OP is =, <, >, <=, or >=), the comparison is done
using DATETIME values, per the fix for
Bug#27590: http://bugs.mysql.com/27590. However that fix
caused any index on date_col not to be used and
compromised performance. Now the index is used again.
* DATETIME arguments specified in numeric form were treated
by DATE_ADD() as DATE values.
* Killing a statement could lead to a race condition in the
server. (Bug#32148: http://bugs.mysql.com/32148)
* InnoDB does not support SPATIAL indexes, but could crash
when asked to handle one. Now an error is returned.
* The server crashed on optimizations involving a join of
INT and MEDIUMINT columns and a system variable in the
WHERE clause. (Bug#32103: http://bugs.mysql.com/32103)
* mysql-test-run.pl used the --user option when starting
mysqld, which produces warnings if the current user is
not root. Now --user is added only for root.
* mysqlslap was missing from the MySQL 5.1.22 Linux RPM
packages. (Bug#32077: http://bugs.mysql.com/32077)
* With lower_case_table_names set, CREATE TABLE LIKE was
treated differently by libmysqld than by the non-embedded
server. (Bug#32063: http://bugs.mysql.com/32063)
* Within a subquery, UNION was handled differently than at
the top level, which could result in incorrect results or
a server crash. (Bug#32036: http://bugs.mysql.com/32036,
* On 64-bit platforms, assignments of values to
enumeration-valued storage engine-specific system
variables were not validated and could result in
* A DELETE statement with a subquery in the WHERE clause
would sometimes ignore an error during subquery
evaluation and proceed with the delete operation.
* Using dates in the range '0000-00-01' to '0000-00-99'
range in the WHERE clause could result in an incorrect
result set. (These dates are not in the supported range
for DATE, but different results for a given query could
occur depending on position of records containing the
dates within a table.)
* User-defined functions are not loaded if the server is
started with the --skip-grant-tables option, but the
server did not properly handle this case and issued an
Out of memory error message instead.
* If a user-defined function was used in a SELECT
statement, and an error occurred during UDF
initialization, the error did not terminate execution of
the SELECT, but rather was converted to a warning.
* HOUR(), MINUTE(), and SECOND() could return non-zero
values for DATE arguments.
* Changing the SQL mode to cause dates with "zero" parts to
be considered invalid (such as '1000-00-00') could result
in indexed and non-indexed searches returning different
results for a column that contained such dates.
* The server used unnecessarily large amounts of memory
when user variables were used as an argument to CONCAT()
or CONCAT_WS(). (Bug#31898: http://bugs.mysql.com/31898)
* In debug builds, testing the result of an IN subquery
against NULL caused an assertion failure.
* SHOW CREATE TRIGGER caused a server crash.
* The server crashed after insertion of a negative value
into an AUTO_INCREMENT column of an InnoDB table.
* For libmysqld applications, handling of
mysql_change_user() calls left some pointers improperly
updated, leading to server crashes.
* Using ORDER BY led to the wrong result when using the
ARCHIVE on a table with a BLOB when the table cache was
full. The table could also be reported as crashed after
the query had completed, even though the table data was
intact. (Bug#31833: http://bugs.mysql.com/31833)
* Comparison results for BETWEEN were different from those
for operators like < and > for DATETIME-like values with
trailing extra characters such as '2007-10-01 00:00:00
GMT-6'. BETWEEN treated the values as DATETIME, whereas
the other operators performed a binary-string comparison.
Now they all uniformly use a DATETIME comparison, but
generate warnings for values with trailing garbage.
* Name resolution for correlated subqueries and HAVING
clauses failed to distinguish which of two was being
performed when there was a reference to an outer aliased
field. This could result in error messages about a HAVING
clause for queries that had no such clause.
* With ONLY_FULL_GROUP_BY SQL mode enabled, queries such as
SELECT a FROM t1 HAVING COUNT(*)>2 were not being
rejected as they should have been.
* The server could crash during filesort for ORDER BY based
on expressions with INET_NTOA() or OCT() if those
functions returned NULL.
* For a fatal error during filesort in find_all_keys(), the
error was returned without the necessary handler
uninitialization, causing an assertion failure. Fixed by
uninitializing the handler before returning the error.
* mysqlslap failed to commit after the final record load.
* The examined-rows count was not incremented for const
queries. (Bug#31700: http://bugs.mysql.com/31700)
* The server crashed if a thread was killed while locking
the general_log table at the beginning of statement
processing. (Bug#31692: http://bugs.mysql.com/31692)
* The mysql_change_user() C API function was subject to
buffer overflow. (Bug#31669: http://bugs.mysql.com/31669)
* For SELECT ... INTO OUTFILE, if the ENCLOSED BY string is
empty and the FIELDS TERMINATED BY string started with a
special character (one of n, t, r, b, 0, Z, or N), every
occurrence of the character within field values would be
duplicated. (Bug#31663: http://bugs.mysql.com/31663)
* SHOW COLUMNS and DESCRIBE displayed null as the column
type for a view with no valid definer. This caused
mysqldump to produce a non-reloadable dump file for the
view. (Bug#31662: http://bugs.mysql.com/31662)
* The mysqlbug script did not include the correct values of
CFLAGS and CXXFLAGS that were used to configure the
distribution. (Bug#31644: http://bugs.mysql.com/31644)
* Queries that include a comparison of an
INFORMATION_SCHEMA table column to NULL caused a server
crash. (Bug#31633: http://bugs.mysql.com/31633)
* EXPLAIN EXTENDED for SELECT from INFORMATION_SCHEMA
tables caused an assertion failure.
* ucs2 does not work as a client character set, but
attempts to use it as such were not rejected. Now
character_set_client cannot be set to ucs2. This also
affects statements such as SET NAMES and SET CHARACTER
SET. (Bug#31615: http://bugs.mysql.com/31615)
* A buffer used when setting variables was not dimensioned
to accommodate the trailing '\0' byte, so a single-byte
buffer overrun was possible.
* HAVING could treat lettercase of table aliases
incorrectly if lower_case_table_names was enabled.
* Spurious duplicate-key errors could occur for
multiple-row inserts into an InnoDB table that activate a
trigger. (Bug#31540: http://bugs.mysql.com/31540)
* Using ALTER EVENT to rename a disabled event caused it to
become enabled. (Bug#31539: http://bugs.mysql.com/31539)
* The fix for Bug#24989: http://bugs.mysql.com/24989
introduced a problem such that a NULL thread handler
could be used during a rollback operation. This problem
is unlikely to be seen in practice.
* The length of the result from IFNULL() could be
calculated incorrectly because the sign of the result was
not taken into account.
* Queries that used the ref access method or index-based
subquery execution over indexes that have DECIMAL columns
could fail with an error Column col_name cannot be null.
* InnoDB now tracks locking and use of tables by MySQL only
after a table has been successfully locked on behalf of a
transaction. Previously, the locked flag was set and the
table in-use counter was updated before checking whether
the lock on the table succeeded. A subsequent failure in
obtaining a lock on the table led to an inconsistent
state as the table was neither locked nor in use.
* SELECT 1 REGEX NULL caused an assertion failure for debug
servers. (Bug#31440: http://bugs.mysql.com/31440)
* The UpdateXML() function did not check for the validity
of all its arguments; in some cases, this could lead to a
crash of the server.
* The mysql_change_user() C API function caused advisory
locks (obtained with GET_LOCK()) to malfunction.
* NDB libraries and include files were missing from some
binary tar file distributions.
* Executing RENAME while tables were open for use with
HANDLER statements could cause a server crash.
For part 2 of the changes, please see the separate mail.
Joerg Bruehe, Senior Production Engineer
MySQL AB, www.mysql.com
Office: (+49 30) 417 01 487 VoIP: firstname.lastname@example.org
to post comments)