Meesterlijk
Verified User
Dear MySQL users,
MySQL 6.0.4-alpha, a new version of the MySQL database system including
the Falcon transactional storage engine (now at beta stage), has been
released. The main page for MySQL 6.0 is at:
http://www.mysql.com/mysql60/
If you are new to the Falcon storage engine and need more information,
please read the Falcon Evaluation Guide at:
http://www.mysql.com/why-mysql/white-papers/falcon-getting-started.php
and the Falcon White Paper at:
http://www.mysql.com/why-mysql/white-papers/storage-engines-falcon.php
MySQL 6.0.4-alpha is available in source and binary form for a number
of platforms from our download pages at
http://dev.mysql.com/downloads/mysql/6.0.html
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.
We welcome and appreciate your feedback, bug reports, bug fixes,
patches etc.:
http://forge.mysql.com/wiki/Contributing
Despite all trimming, describing all changes since the last released
version of MySQL 6.0 exceeds the mailing list configuration.
We had to split this message into two parts, this one (part 1) lists all
changes which are labeled "functionality", "security", "incompatible",
or "important".
You can view the full list online at
http://dev.mysql.com/doc/refman/6.0/en/news-6-0-4.html
"Functionality", "security", "incompatible", or "important" changes
since the last release:
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 partitioned tables.
(Bug#32091: http://bugs.mysql.com/32091, CVE-2007-5970
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5970))
See also Bug#29325: http://bugs.mysql.com/29325,
Bug#32111: http://bugs.mysql.com/32111
* Incompatible Change: The Unicode implementation has been
extended to provide support for supplementary characters that
lie outside the Basic Multilingual Plane (BMP). Noteworthy
features:
+ utf16 and utf32 character sets have been added. These correspond to
the UTF-16 and UTF-32 encodings of the Unicode character set, and
they both support supplementary characters.
+ The utf8 character set from previous versions of MySQL
has been renamed to utf8mb3, to reflect that its encoding
uses a maximum of three bytes for multi-byte characters.
(Old tables that previously used utf8 will be reported as
using utf8mb3 after an in-place upgrade to MySQL 6.0, but
otherwise work as before.)
+ The new utf8 character set in MySQL 6.0 is similar to
utf8mb3, but its encoding allows up to four bytes per
character to enable support for supplementary characters.
+ The ucs2 character set is essentially unchanged except
for the inclusion of some newer BMP characters.
In most respects, upgrading from MySQL 5.1 to 6.0 should
present few problems with regard to Unicode usage, although
there are some potential areas of incompatibility. Some
examples:
+ For the variable-length character data types (VARCHAR and
the TEXT types), the maximum length in characters for
utf8 columns is less in MySQL 6.0 than previously.
+ For all character data types (CHAR, VARCHAR, and the TEXT
types), the maximum number of characters for utf8 columns
that can be indexed is less in MySQL 6.0 than previously.
Consequently, if you want to upgrade tables from the old utf8
(now utf8mb3) to the current utf8, it may be necessary to
change some column or index definitions.
For additional details about the new Unicode character sets
and potential incompatibilities, see Section 9.1.8, "Unicode
Support," and Section 9.1.9, "Upgrading from Previous to
Current Unicode Support."
If you use events, a known issue is that if you upgrade from
MySQL 5.1 to 6.0.4, the event scheduler will not work, even
after you run mysql_upgrade. (This is an issue only for an
upgrade, not for a new installation of MySQL 6.0.4.) To work
around this upgrading problem, use these instructions:
1. In MySQL 5.1, before upgrading, create a dump file
containing your mysql.event table:
shell> mysqldump -uroot -p mysql event > event.sql
2. Stop the server, upgrade to MySQL 6.0, and start the server.
3. Recreate the mysql.event table using the dump file:
shell> mysql -uroot -p mysql < event.sql
4. Run mysql_upgrade to upgrade the other system tables in
the mysql database:
shell> mysql_upgrade -uroot -p
5. Restart the server. The event scheduler should run normally.
* Incompatible Change: Because of a change in the format of the
Falcon pages stored within Falcon database files, Falcon
databases created in MySQL 6.0.4 (or later) are not compatible
with previous releases, and existing Falcon databases are
incompatible with MySQL 6.0.4 (and later versions. You should
dump Falcon databases using mysqldump before upgrading, and
then reload them after the upgrade. For more information, see
Section 4.5.4, "mysqldump --- A Database Backup Program."
* Partitioning: Error messages for partitioning syntax errors
have been made more descriptive.
(Bug#29368: http://bugs.mysql.com/29368)
* Replication: Replication of the following now switches to row-based
logging in MIXED mode, and generates a warning in STATEMENT mode:
+ USER()
+ CURRENT_USER()
+ CURRENT_USER
+ FOUND_ROWS()
+ ROW_COUNT()
See Section 5.2.4.3, "Mixed Binary Logging (MBL) Format," for
more information. (Bug#12092: http://bugs.mysql.com/12092,
Bug#28086: http://bugs.mysql.com/28086,
Bug#30244: http://bugs.mysql.com/30244)
* Cluster Replication: A replication heartbeat mechanism has been added
to facilitate monitoring. This provides an alternative to checking log
files, making it possible to detect in real time when a slave has
failed. Configuration of heartbeats is done via a new
MASTER_HEARTBEAT_PERIOD = interval clause for the CHANGE MASTER TO
statement (see Section 12.6.2.1, "CHANGE MASTER TO Syntax");
monitoring can be done by checking the values of the status variables
Slave_heartbeat_period and Slave_received_heartbeats (see Section
5.1.5, "Status Variables").
The addition of replication heartbeats addresses a number of issues:
+ Relay logs were rotated every slave_net_timeout seconds
even if no statements were being replicated.
+ SHOW SLAVE STATUS displayed an incorrect value for
seconds_behind_master following a FLUSH LOGS statement.
+ Replication master-slave connections used
slave_net_timeout for connection timeouts.
(Bug#20435: http://bugs.mysql.com/20435,
Bug#29309: http://bugs.mysql.com/29309,
Bug#30932: http://bugs.mysql.com/30932)
* The --event-scheduler option without a value disabled the event
scheduler. Now it enables the event scheduler.
(Bug#31332: http://bugs.mysql.com/31332)
* 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 taken 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)
* 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. (Bug#28184: http://bugs.mysql.com/28184)
* It is now possible to set long_query_time in microseconds or to 0.
Setting this value to 0 causes all queries to be recorded in the slow
query log.
Currently, fractional values can be used only when logging to files.
We plan to provide this functionality for logging to tables when
time-related data types are enhanced to support microsecond
resolution. (Bug#25412: http://bugs.mysql.com/25412)
* INFORMATION_SCHEMA implementation changes were made that optimize
certain types of queries for INFORMATION_SCHEMA tables so that they
execute more quickly. Section 7.2.17, "INFORMATION_SCHEMA
Optimization," provides guidelines on how to take advantage of these
optimizations by writing queries that minimize the need for the server
to access the filesystem to obtain the information contained in
INFORMATION_SCHEMA tables. By writing queries that enable the server
to avoid directory scans or opening table files, you will obtain
better performance. (Bug#19588: http://bugs.mysql.com/19588)
* Three options were added to mysqldump make it easier to generate a
dump from a slave server. --dump-slave is similar to --master-data,
but the CHANGE MASTER statement contains binary log coordinates for
the slave's master host, not the slave itself.
--apply-slave-statements causes STOP SLAVE and START SLAVE statements
to be added before the CHANGE MASTER statement and at the end of the
output, respectively. --include-master-host-port causes the CHANGE
MASTER statement to include MASTER_PORT and MASTER_HOST options for
the slave's master. (Bug#8368: http://bugs.mysql.com/8368)
* An alternative thread model is available for dealing with the issues
that occur with the original one-thread-per-client model when scaling
to large numbers of simultaneous connections. This model uses thread
pooling:
+ Connection manager threads do not dedicate a thread to each client
connection. Instead, the connection is added to the set of existing
connection sockets. The server collects input from these sockets and
when a complete request has been received from a given client, it is
queued for service.
+ The server maintains a pool of service threads to process requests.
When a queued request is waiting and there is an available (not
busy) service thread in the pool, the request is given to the thread
to be handled. After processing the request, the service thread
becomes available to process other requests.
Service threads are created at server startup and exist until the
server terminates. A given service thread is not tied to a specific
client connection and the requests that it processes over time may
originate from different client connections.
+ The pool of service threads has a fixed size, so the amount of
memory required for it does not increase as the number of client
connections increases.
For information about choosing one thread model over the other and
tuning the parameters that control thread resources, see Section
7.5.7, "How MySQL Uses Threads for Client Connections."
* When the server detects MyISAM table corruption, it now writes
additional information to the error log, such as the name and
line number of the source file, and the list of threads accessing
the table. Example: Got an error from thread_id=1, mi_dynrec.c:368.
This is useful information to include in bug reports.
* Two options relating to slow query logging have been added for mysqld.
--log-slow-slave-statements causes slow statements executed by a
replication slave to be written to the slow query log;
in_examined_row_limit can be used to cause queries which examine fewer
than the stated number of rows not to be logged.
Bugs fixed:
* 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, CVE-2007-6313
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6313))
* 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 OpenSSL.
Note:
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
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0226),
CVE-2008-0227
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0227))
* 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 symlink points. 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
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=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. (Bug#29908: http://bugs.mysql.com/29908)
* 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. (Bug#29801: http://bugs.mysql.com/29801)
* Important Change: Incompatible Change: A number of problems
existed in the implementation of MERGE tables that could cause
problems. The problems are summarized below:
+ 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 hogging.
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 the server.
+ Bug#25038: http://bugs.mysql.com/25038 - Waiting TRUNCATE
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 TABLE
Repairing a child of an open MERGE table corrupted the child. It was
necessary to FLUSH the child first.
+ Bug#30275: http://bugs.mysql.com/30275 - MERGE tables:
FLUSH TABLES or UNLOCK TABLES causes server to crash.
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 non-MyISAM children.
+ 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 (errno: 155)".
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 Bug#19627: http://bugs.mysql.com/19627.
+ 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 table.
+ You cannot create a MERGE table with CREATE ... SELECT, neither as a
temporary MERGE table, nor as a non-temporary MERGE table. Example:
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...;
gives error message: table is not BASE TABLE.
(Bug#19627: http://bugs.mysql.com/19627,
Bug#25038: http://bugs.mysql.com/25038,
Bug#25700: http://bugs.mysql.com/25700,
Bug#26377: http://bugs.mysql.com/26377,
Bug#26379: http://bugs.mysql.com/26379,
Bug#26867: http://bugs.mysql.com/26867,
Bug#27660: http://bugs.mysql.com/27660,
Bug#30275: http://bugs.mysql.com/30275,
Bug#30491: http://bugs.mysql.com/30491)
* Incompatible Change: SET PASSWORD statements now cause an implicit
commit, and thus are prohibited within stored functions and triggers.
(Bug#30904: http://bugs.mysql.com/30904)
* 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: 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.
(Bug#20748: http://bugs.mysql.com/20748)
* 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.
(Bug#30695: http://bugs.mysql.com/30695)
MySQL 6.0.4-alpha, a new version of the MySQL database system including
the Falcon transactional storage engine (now at beta stage), has been
released. The main page for MySQL 6.0 is at:
http://www.mysql.com/mysql60/
If you are new to the Falcon storage engine and need more information,
please read the Falcon Evaluation Guide at:
http://www.mysql.com/why-mysql/white-papers/falcon-getting-started.php
and the Falcon White Paper at:
http://www.mysql.com/why-mysql/white-papers/storage-engines-falcon.php
MySQL 6.0.4-alpha is available in source and binary form for a number
of platforms from our download pages at
http://dev.mysql.com/downloads/mysql/6.0.html
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.
We welcome and appreciate your feedback, bug reports, bug fixes,
patches etc.:
http://forge.mysql.com/wiki/Contributing
Despite all trimming, describing all changes since the last released
version of MySQL 6.0 exceeds the mailing list configuration.
We had to split this message into two parts: part 1 (the other)
lists all changes which are labeled "functionality", "security",
"incompatible", or "important",
while this one lists the changes without such a label.
You can view the full list online at
http://dev.mysql.com/doc/refman/6.0/en/news-6-0-4.html
Changes since the last release:
...
Bugs fixed (part 2):
* Partitioning: MySQL Cluster: EXPLAIN PARTITIONS reported partition
usage by queries on NDB tables according to the standard MySQL hash
function than the hash function used in the NDB storage engine.
(Bug#29550: http://bugs.mysql.com/29550)
* 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,
Bug#30790: http://bugs.mysql.com/30790)
See also Bug#24231: http://bugs.mysql.com/24231,
Bug#30024: http://bugs.mysql.com/30024,
Bug#30133: http://bugs.mysql.com/30133,
Bug#30134: http://bugs.mysql.com/30134
* MySQL Cluster: An insert or update with combined range and equality
constraints failed when run against an NDB table with the error Got
unknown error from NDB. An example of such a statement would be UPDATE
t1 SET b = 5 WHERE a IN (7,8) OR a >= 10;.
(Bug#31874: http://bugs.mysql.com/31874)
* 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.
(Bug#31810: http://bugs.mysql.com/31810)
* MySQL Cluster: The NDB storage engine code was not safe for
strict-alias optimization in gcc 4.2.1.
(Bug#31761: http://bugs.mysql.com/31761)
* MySQL Cluster: Following an upgrade, ndb_mgmd would fail with
an ArbitratiDN_XSS_NEUTRALIZE_onError. (Bug#31690: http://bugs.mysql.com/31690)
* MySQL Cluster: It was possible in some cases for a node group to be
"lost" due to missed local checkpoints following a system restart.
(Bug#31525: http://bugs.mysql.com/31525)
* 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.
(Bug#31482: http://bugs.mysql.com/31482)
This regression was introduced by
Bug#29102: http://bugs.mysql.com/29102
* MySQL Cluster: NDB tables having names containing
non-alphanumeric characters (such as " $ ") were not
discovered correctly. (Bug#31470: http://bugs.mysql.com/31470)
* MySQL Cluster: A node failure during a local checkpoint could
lead to a subsequent failure of the cluster during a system
restart. (Bug#31257: http://bugs.mysql.com/31257)
* 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. (Bug#29509: http://bugs.mysql.com/29509)
* MySQL Cluster: An interpreted program of sufficient size and
complexity could cause all cluster data nodes to shut down due
to buffer overruns. (Bug#29390: http://bugs.mysql.com/29390)
* MySQL Cluster: Performing DELETE operations after a data node
had been shut down could lead to inconsistent data following a
restart of the node. (Bug#26450: http://bugs.mysql.com/26450)
* 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.
(Bug#25817: http://bugs.mysql.com/25817)
* MySQL Cluster: The cluster log was formatted inconsistently
and contained extraneous newline characters.
(Bug#25064: http://bugs.mysql.com/25064)
* MySQL Cluster: (Replication): Inconsistencies could occur
between the master and the slave when replicating Disk Data
tables. (Bug#19259: http://bugs.mysql.com/19259,
Bug#19227: http://bugs.mysql.com/19227)
* Partitioning: Repeated updates of a table that was partitioned
by KEY on a TIMESTAMP column eventually crashed the server.
(Bug#32067: http://bugs.mysql.com/32067)
* Partitioning: Selecting from a table partitioned by KEY on a
VARCHAR column whose size was greater than 65530 caused the
server to crash. (Bug#31705: http://bugs.mysql.com/31705)
* Partitioning: INSERT DELAYED into a partitioned table crashed
the server. (Bug#31201: http://bugs.mysql.com/31201)
* 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
Bug#27405: http://bugs.mysql.com/27405
* Partitioning: Falcon cannot drop a table for which there is a
pending transaction, but the error message for such attempts
was misleading. (Bug#22972: http://bugs.mysql.com/22972)
* 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 statement-based
replication. (Bug#32435: http://bugs.mysql.com/32435)
* 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.
(Bug#31836: http://bugs.mysql.com/31836)
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.
(Bug#31702: http://bugs.mysql.com/31702)
* 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.
(Bug#30752: http://bugs.mysql.com/30752)
* Replication: It was possible to set SQL_SLAVE_SKIP_COUNTER
such that the slave would jump into the middle of an event
group, including possibly a transaction.
(Bug#28618: http://bugs.mysql.com/28618)
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.
(Bug#28597: http://bugs.mysql.com/28597,
Bug#28603: http://bugs.mysql.com/28603)
See also Bug#31836: http://bugs.mysql.com/31836
This regression was introduced by
Bug#20166: http://bugs.mysql.com/20166
* Replication: Stored procedures having BIT parameters were not
replicated correctly. (Bug#26199: http://bugs.mysql.com/26199)
* Replication: Issuing SHOW SLAVE STATUS as mysqld was shutting
down could cause a crash.
(Bug#26000: http://bugs.mysql.com/26000)
* 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 executed
successfully. (Bug#24860: http://bugs.mysql.com/24860)
See also Bug#12691: http://bugs.mysql.com/12691,
Bug#23171: http://bugs.mysql.com/23171
* 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.
(Bug#21132: http://bugs.mysql.com/21132)
See also Bug#13963: http://bugs.mysql.com/13963,
Bug#21869: http://bugs.mysql.com/21869
* 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.
(Bug#19958: http://bugs.mysql.com/19958)
* 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. (Bug#33375: http://bugs.mysql.com/33375)
* Cluster Replication: A node failure during replication could
lead to buckets out of order; now active subscribers are
checked for, rather than empty buckets.
(Bug#31701: http://bugs.mysql.com/31701)
* Cluster Replication: In some cases, not all tables were
properly initialized before the binlog thread was started.
(Bug#31618: http://bugs.mysql.com/31618)
* Using Falcon when accessing multiple versions of the same
record, certain records could fail to be retrieved from the
record cache, causing an assertion failure.
(Bug#32862: http://bugs.mysql.com/32862)
* Creating an index on a Falcon table with a column using UTF32
that has been converted to UTF8 would cause a server crash.
(Bug#32833: http://bugs.mysql.com/32833)
* Using ALTER TABLE on a Falcon table it would be possible to
create two tables with the same name but different case.
(Bug#32830: http://bugs.mysql.com/32830)
* Converting a table from InnoDB to Falcon, where the Falcon
table with the same name (but different case) would cause a
server crash. (Bug#32829: http://bugs.mysql.com/32829)
* mysqld_safe looked for error messages in the wrong location.
(Bug#32679: http://bugs.mysql.com/32679)
* An issue with the NO_ENGINE_SUBSTITUTION sql_mode database can
cause the creation of stored routines to fail. If you are
having problems with creating stored routines while using this
sql_mode value, remove this value from your sql_mode setting.
(Bug#32633: http://bugs.mysql.com/32633)
* Repeatedly creating and dropping Falcon tablespaces would fail
because a dropped tablespace would not be dropped before the
new tablespace file was created.
(Bug#32621: http://bugs.mysql.com/32621)
* The INTERVAL() function incorrectly handled NULL values in the
value list. (Bug#32560: http://bugs.mysql.com/32560)
* Use of a NULL-returning GROUP BY expression in conjunction
with WITH ROLLUP could cause a server crash.
(Bug#32558: http://bugs.mysql.com/32558)
See also Bug#31095: http://bugs.mysql.com/31095
* ORDER BY UpdateXML(...) caused the server to crash in queries
where UpdateXML() returned NULL.
(Bug#32557: http://bugs.mysql.com/32557)
* Falcon used a fixed index key size which would be too small to
cope with some Falcon page sizes, leading to a crash. Falcon
now supports variable length index keys according to the
supported page sizes. See falcon_page_size.
(Bug#32554: http://bugs.mysql.com/32554)
* The rules for valid column names were being applied differently for
base tables and views. (Bug#32496: http://bugs.mysql.com/32496)
* Falcon options to set the limits of memory usage would not be
honoured. This could lead to crashes and assertions during
normal usage, instead of generating a suitable warning.
(Bug#32413: http://bugs.mysql.com/32413)
* Falcon would incorrectly return the supported repeatable-read
level when queried by the Online Backup system, preventing the
ability to create a consistent snapshot backup.
(Bug#32301: http://bugs.mysql.com/32301)
* Some uses of user variables in a query could result in a
server crash. (Bug#32260: http://bugs.mysql.com/32260)
* Under certain conditions, the presence of a GROUP BY clause
could cause an ORDER BY clause to be ignored.
(Bug#32202: http://bugs.mysql.com/32202)
* Altering a Falcon table to support an auto increment column on
a column with existing data and null values would incorrectly
update the table and return an incorrect count of the altered
rows. (Bug#32194: http://bugs.mysql.com/32194)
* InnoDB does not support SPATIAL indexes, but could crash when
asked to handle one. Now an error is returned.
(Bug#32125: http://bugs.mysql.com/32125)
* 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.
(Bug#32078: http://bugs.mysql.com/32078)
* Inserting, updating and deleting a large number of BLOB records in a
Falcon table would take significant amount of time and may prevent
shutdown. (Bug#32062: http://bugs.mysql.com/32062)
* On 64-bit platforms, assignments of values to enumeration-valued
storage engine-specific system variables were not validated and could
result in unexpected values. (Bug#32034: http://bugs.mysql.com/32034)
* A DELETE statement with a subquery in the WHERE clause would sometimes
ignore an error during subquery evaluation and proceed with the delete
operation. (Bug#32030: http://bugs.mysql.com/32030)
* 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.) (Bug#32021: http://bugs.mysql.com/32021)
* 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. (Bug#32020: http://bugs.mysql.com/32020)
* 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. (Bug#32007: http://bugs.mysql.com/32007)
* In debug builds, testing the result of an IN subquery against
NULL caused an assertion failure.
(Bug#31884: http://bugs.mysql.com/31884)
* SHOW CREATE TRIGGER caused a server crash.
(Bug#31866: http://bugs.mysql.com/31866)
* The server crashed after insertion of a negative value into an
AUTO_INCREMENT column of an InnoDB table.
(Bug#31860: http://bugs.mysql.com/31860)
* For libmysqld applications, handling of mysql_change_user()
calls left some pointers improperly updated, leading to server
crashes. (Bug#31850: http://bugs.mysql.com/31850)
* 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'.
(Bug#31800: http://bugs.mysql.com/31800)
* 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. (Bug#31794: http://bugs.mysql.com/31794)
* The server could crash during filesort for ORDER BY based on
expressions with INET_NTOA() or OCT() if those functions
returned NULL. (Bug#31758: http://bugs.mysql.com/31758)
* 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. (Bug#31742: http://bugs.mysql.com/31742)
* The examined-rows count was not incremented for const queries.
(Bug#31700: http://bugs.mysql.com/31700)
* Falcon tables would fail during replication if ROW-based
replication was specified. (Bug#31671: http://bugs.mysql.com/31671)
* 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)
* For queries for which loose index scan is applicable, the
optimizer could choose the wrong execution plan for correlated
subqueries. (Bug#31639: http://bugs.mysql.com/31639)
* 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.
(Bug#31630: http://bugs.mysql.com/31630)
* A buffer used when setting variables was not dimensioned to
accommodate the trailing '\0' byte, so a single-byte buffer
overrun was possible. (Bug#31588: http://bugs.mysql.com/31588)
* For semi-join processing, pullout of functionally dependent
tables was not handled transitively.
(Bug#31563: http://bugs.mysql.com/31563)
* HAVING could treat lettercase of table aliases incorrectly if
lower_case_table_names was enabled.
(Bug#31562: http://bugs.mysql.com/31562)
* 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)
* When inserting dates into a DATETIME column with a Falcon, the
values would automatically be converted with values between 70
and 99 converted to 1970-1999, and values from 00 to 69
converted to 2000 to 2069. These dates are now correctly
handled. (Bug#31490: http://bugs.mysql.com/31490)
* The length of the result from IFNULL() could be calculated
incorrectly because the sign of the result was not taken into
account. (Bug#31471: http://bugs.mysql.com/31471)
* 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.
(Bug#31450: http://bugs.mysql.com/31450)
* 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.
(Bug#31444: http://bugs.mysql.com/31444)
* SELECT 1 REGEX NULL caused an assertion failure for debug
servers. (Bug#31440: http://bugs.mysql.com/31440)
* INFORMATION_SCHEMA.TABLES was returning incorrect information.
(Bug#31381: http://bugs.mysql.com/31381)
* DROP USER caused an increase in memory usage.
(Bug#31347: http://bugs.mysql.com/31347)
* TABLESPACE names within Falcon did not support characters
outside the alpha-numeric ASCII character set.
(Bug#31311: http://bugs.mysql.com/31311)
* For InnoDB tables with READ COMMITTED isolation level, UPDATE
statements skipped rows locked by another transaction, rather
than waiting for the locks to be released.
(Bug#31310: http://bugs.mysql.com/31310)
* For an almost-full MyISAM table, an insert that failed could
leave the table in a corrupt state.
(Bug#31305: http://bugs.mysql.com/31305)
* When dropping Falcon tablespaces the associated tablespace
file would not be deleted. (Bug#31296: http://bugs.mysql.com/31296)
* myisamchk --unpack could corrupt a table that when unpacked has static
(fixed-length) row format. (Bug#31277: http://bugs.mysql.com/31277)
* Building a 64-bit binary with support for the Falcon storage
engine using gcc on Solaris could fail. See Section 2.9,
"MySQL Installation Using a Source Distribution," for more
information. (Bug#31268: http://bugs.mysql.com/31268,
Bug#33126: http://bugs.mysql.com/33126)
* When a TIMESTAMP with a non-zero time part was converted to a
DATE value, no warning was generated. This caused index
lookups to assume that this is a valid conversion and was
returning rows that match a comparison between a TIMESTAMP
value and a DATE keypart. Now a warning is generated so that
TIMESTAMP with a non-zero time part will not match DATE
values. (Bug#31221: http://bugs.mysql.com/31221)
* If MAKETIME() returned NULL when used in an ORDER BY that was
evaluated using filesort, a server crash could result.
(Bug#31160: http://bugs.mysql.com/31160)
* LAST_INSERT_ID() execution could be handled improperly in
subqueries. (Bug#31157: http://bugs.mysql.com/31157)
* An assertion designed to detect a bug in the ROLLUP implementation
would incorrectly be triggered when used in a subquery context with
non-cacheable statements. (Bug#31156: http://bugs.mysql.com/31156)
* When creating a TABLESPACE that uses the same name as an existing
TABLESPACE, Falcon would return Unknown error -103. MySQL will now
return an error stating that the specified tablespace already exists.
(Bug#31114: http://bugs.mysql.com/31114)
* mysqldump failed to handle databases containing a `-' character
in the name. (Bug#31113: http://bugs.mysql.com/31113)
* Starting the server using --read-only and with the Event Scheduler
enabled caused it to crash. (Bug#31111: http://bugs.mysql.com/31111)
* Dropping a tablespace and specifying an engine type that does not
support tablespaces would report a warning. The response has now been
updated to report an error. (Bug#31110: http://bugs.mysql.com/31110)
* GROUP BY NULL WITH ROLLUP could cause a server crash.
(Bug#31095: http://bugs.mysql.com/31095)
See also Bug#32558: http://bugs.mysql.com/32558
* A rule to prefer filesort over an indexed ORDER BY when
accessing all rows of a table was being used even if a LIMIT
clause was present. (Bug#31094: http://bugs.mysql.com/31094)
* REGEXP operations could cause a server crash for character sets such
as ucs2. Now the arguments are converted to utf8 if possible, to allow
correct results to be produced if the resulting strings contain only
8-bit characters. (Bug#31081: http://bugs.mysql.com/31081)
* Expressions of the form WHERE col NOT IN (col, ...), where the
same column was named both times, could cause a server crash
in the optimizer. (Bug#31075: http://bugs.mysql.com/31075)
* Falcon would fail to compile on FreeBSD. This limitation has
now been fixed. (Bug#31045: http://bugs.mysql.com/31045)
* Using ORDER BY with ARCHIVE tables caused a server crash.
(Bug#31036: http://bugs.mysql.com/31036)
* The MOD() function and the % operator crashed the server for a
divisor less than 1 with a very long fractional part.
(Bug#31019: http://bugs.mysql.com/31019)
* Using falcon_serial_log_dir to set the location of the Falcon
serial log would have no effect.
(Bug#31005: http://bugs.mysql.com/31005)
* The LooseScan subquery optimization strategy could produce
duplicate rows in query results.
(Bug#30993: http://bugs.mysql.com/30993)
* A character set introducer followed by a hexadecimal or bit-value
literal did not check its argument and could return an ill-formed
result for invalid input. (Bug#30986: http://bugs.mysql.com/30986)
* CHAR(str USING charset) did not check its argument and could
return an ill-formed result for invalid input.
(Bug#30982: http://bugs.mysql.com/30982)
* The result from CHAR(str USING ucs2) did not add a leading
0x00 byte for input strings with an odd number of bytes.
(Bug#30981: http://bugs.mysql.com/30981)
* A cluster restart could sometimes fail due to an issue with
table IDs. (Bug#30975: http://bugs.mysql.com/30975)
* The GeomFromText() function could cause a server crash if the
first argument was NULL or the empty string.
(Bug#30955: http://bugs.mysql.com/30955)
* When invoked with constant arguments, STR_TO_DATE() could use
a cached value for the format string and return incorrect
results. (Bug#30942: http://bugs.mysql.com/30942)
* GROUP_CONCAT() returned ',' rather than an empty string when
the argument column contained only empty strings.
(Bug#30897: http://bugs.mysql.com/30897)
* A server crash could occur if a stored function that contained
a DROP TEMPORARY TABLE statement was invoked by a CREATE
TEMPORARY TABLE statement that created a table of the same
name. (Bug#30882: http://bugs.mysql.com/30882)
* Calling NAME_CONST() with non-constant arguments triggered an
assertion failure. Non-constant arguments are now disallowed.
(Bug#30832: http://bugs.mysql.com/30832)
* Running ALTER TABLE ... OPTIMIZE PARTITION on a Falcon table,
a 'divide by zero' error would be reported during a server
crash. (Bug#30826: http://bugs.mysql.com/30826)
* For a spatial column with a regular (non-SPATIAL) index,
queries failed if the optimizer tried to use the index.
(Bug#30825: http://bugs.mysql.com/30825)
* INFORMATION_SCHEMA.SCHEMATA was returning incorrect information.
(Bug#30795: http://bugs.mysql.com/30795)
* On Windows, the pthread_mutex_trylock() implementation was incorrect.
One symptom was that invalidating the query cache could cause a server
crash. (Bug#30768: http://bugs.mysql.com/30768)
* A multiple-table UPDATE involving transactional and non-transactional
tables caused an assertion failure.
(Bug#30763: http://bugs.mysql.com/30763)
* Under some circumstances, CREATE TABLE ... SELECT could crash
the server or incorrectly report that the table row size was
too large. (Bug#30736: http://bugs.mysql.com/30736)
* Using the MIN() or MAX() function to select one part of a
multi-part key could cause a crash when the function result
was NULL. (Bug#30715: http://bugs.mysql.com/30715)
* INFORMATION_SCHEMA.VIEWS.VIEW_DEFINITION was incorrect for views that
were defined to select from other INFORMATION_SCHEMA tables.
(Bug#30689: http://bugs.mysql.com/30689)
* Issuing an ALTER SERVER statement to update the settings for a
FEDERATED server would cause the mysqld to crash.
(Bug#30671: http://bugs.mysql.com/30671)
* The optimizer could ignore ORDER BY in cases when the result
set is ordered by filesort, resulting in rows being returned
in incorrect order. (Bug#30666: http://bugs.mysql.com/30666)
* A different execution plan was displayed for EXPLAIN than
would actually have been used for the SELECT because the test
of sort keys for ORDER BY did not consider keys mentioned in
IGNORE KEYS FOR ORDER BY.
(Bug#30665: http://bugs.mysql.com/30665)
* MyISAM tables could not exceed 4294967295 (2^32 - 1) rows on
Windows. (Bug#30638: http://bugs.mysql.com/30638)
* mysql-test-run.pl could not run mysqld with root privileges.
(Bug#30630: http://bugs.mysql.com/30630)
* Using GROUP BY on an expression of the form timestamp_col DIV
number caused a server crash due to incorrect calculation of
number of decimals. (Bug#30587: http://bugs.mysql.com/30587)
* The options available to the CHECK TABLE statement were also
allowed in OPTIMIZE TABLE and ANALYZE TABLE statements, but
caused corruption during their execution. An error is now
raised if you try to apply these options to these statements.
(Bug#30495: http://bugs.mysql.com/30495)
* When expanding a * in a USING or NATURAL join, the check for
table access for both tables in the join was done using only
the grant information of the first table.
(Bug#30468: http://bugs.mysql.com/30468)
* Compared to MySQL 5.1, the 6.0 optimizer failed to use join
buffering for certain queries, resulting in slower performance
for those queries. (Bug#30363: http://bugs.mysql.com/30363)
* A table-access check was performed improperly by libmysqld,
causing a crash. (Bug#30329: http://bugs.mysql.com/30329)
* Some valid euc-kr characters having the second byte in the
ranges [0x41..0x5A] and [0x61..0x7A] were rejected.
(Bug#30315: http://bugs.mysql.com/30315)
* When loading a dynamic plugin on FreeBSD, the plugin would fail to
load. This was due to a build error where the required symbols would
be not exported correctly. (Bug#30296: http://bugs.mysql.com/30296)
* Setting certain values on a table using a spatial index could cause
the server to crash. (Bug#30286: http://bugs.mysql.com/30286)
* Some INFORMATION_SCHEMA tables are intended for internal use, but
could be accessed by using SHOW statements.
(Bug#30079: http://bugs.mysql.com/30079)
* On some 64-bit systems, inserting the largest negative value into a
BIGINT column resulted in incorrect data.
(Bug#30069: http://bugs.mysql.com/30069)
* mysqlslap did not properly handle multiple result sets from
stored procedures. (Bug#29985: http://bugs.mysql.com/29985)
* Running the sqlbench test suite against Falcon would cause a
crash. (Bug#29870: http://bugs.mysql.com/29870)
* When accessing statistics in INFORMATION_SCHEMA.FALCON_DATABASE_IO,
the information would relate only to the Falcon database, not user
tablespaces. (Bug#29823: http://bugs.mysql.com/29823)
* Whitespace characters other than spaces within XML tags, such
as linefeeds or tabs, caused LOAD XML INFILE to skip rows.
(Bug#29752: http://bugs.mysql.com/29752)
* configure did not find nss on some Linux platforms.
(Bug#29658: http://bugs.mysql.com/29658)
* Compilation failed on systems where a native log2() implementation was
unavailable. (Bug#29640: http://bugs.mysql.com/29640)
* Use of the latin2_czech_cs collation caused a server crash.
(Bug#29459: http://bugs.mysql.com/29459)
* Using two simultaneous connections it was possible to create a
deadlock situation between two different active transactions on the
same Falcon table. There is no way to prevent this, but a new
parameter, falcon_lock_timeout can set the timeout for deadlocked
transactions. The default timeout is 0 (timeouts are disabled).
(Bug#29452: http://bugs.mysql.com/29452)
* The mysql client program now ignores Unicode byte order mark
(BOM) characters at the beginning of input files. Previously,
it read them and sent them to the server, resulting in a
syntax error. (Bug#29323: http://bugs.mysql.com/29323)
* Insert information into the same table from multiple threads could
cause duplicate key errors. This was related to the changes made to
allow compatibility with the InnoDB repeatable-read isolation level.
The option, falcon_innodb_compatibility, has been renamed to
falcon_consistent_read, but with the opposite effect. The default is
for this option to be on. When set to off, the behaviour of Falcon is
similar to that in InnoDB. (Bug#29151: http://bugs.mysql.com/29151)
* For transactional tables, an error during a multiple-table DELETE
statement did not roll back the statement.
(Bug#29136: http://bugs.mysql.com/29136)
* The log and log_slow_queries system variables were displayed by SHOW
VARIABLES but could not be accessed in expressions as @@log and
@@log_slow_queries. (Bug#29131: http://bugs.mysql.com/29131)
* When loading large data sets using LOAD DATA INFILE into a Falcon
table, the server could crash.
(Bug#29081: http://bugs.mysql.com/29081)
* SHOW VARIABLES did not display the relay_log, relay_log_index,
or relay_log_info_file system variables.
(Bug#28893: http://bugs.mysql.com/28893)
* Index hints specified in view definitions were ignored when using the
view to select from the base table.
(Bug#28702: http://bugs.mysql.com/28702)
* Views do not have indexes, so index hints do not apply. Use of
index hints when selecting from a view is now disallowed.
(Bug#28701: http://bugs.mysql.com/28701)
* After changing the SQL mode to a restrictive value that would
make already-inserted dates in a column be considered invalid,
searches returned different results depending on whether the
column was indexed. (Bug#28687: http://bugs.mysql.com/28687)
* The result from CHAR() was incorrectly assumed in some contexts to
return a single-byte result. (Bug#28550: http://bugs.mysql.com/28550)
* Using a temporary table within Falcon that is created in a
directory where the path contains a mixture of upper and lower
letters would fail. (Bug#28541: http://bugs.mysql.com/28541)
* Under heavy load when updating Falcon tables, a race condition
could occur that would ultimately result in a crash.
(Bug#28519: http://bugs.mysql.com/28519)
* The result of a comparison between VARBINARY and BINARY
columns differed depending on whether the VARBINARY column was
indexed. (Bug#28076: http://bugs.mysql.com/28076)
* The metadata in some MYSQL_FIELD members could be incorrect
when a temporary table was used to evaluate a query.
(Bug#27990: http://bugs.mysql.com/27990)
* It was possible to create a view having a column whose name
consisted of an empty string or space characters only.
(Bug#27695: http://bugs.mysql.com/27695)
See also Bug#31202: http://bugs.mysql.com/31202
* ALTER TABLE tbl_name ROW_FORMAT=format_type did not cause the
table to be rebuilt. (Bug#27610: http://bugs.mysql.com/27610)
* Searching a Falcon table that uses DATETIME columns with an index
could return incorrect results.
(Bug#27426: http://bugs.mysql.com/27426)
* Removing a partition on a Falcon table when there are two
tables with the same name, but different case, would cause a
crash during normal shutdown. (Bug#27425: http://bugs.mysql.com/27425)
* Mixing differently cased tables between MyISAM and Falcon
tables would cause a crash. (Bug#27424: http://bugs.mysql.com/27424)
* The ExtractValue() and UpdateXML() functions performed extremely
slowly for large amounts of XML data (greater than 64 KB). These
functions now execute approximately 2000 times faster than previously.
(Bug#27287: http://bugs.mysql.com/27287)
* On Windows, writes to the debug log were using freopen() instead of
fflush(), resulting in slower performance.
(Bug#27099: http://bugs.mysql.com/27099)
* Connections from one mysqld server to another failed on Mac OS X,
affecting replication and FEDERATED tables.
(Bug#26664: http://bugs.mysql.com/26664)
See also Bug#29083: http://bugs.mysql.com/29083
* LOAD DATA INFILE ran very slowly when reading large files into
partitioned tables. (Bug#26527: http://bugs.mysql.com/26527)
* 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 EXPLAIN), the query in the
statistics state (shown by the SHOW PROCESSLIST) did not respond to
the KILL statement. (Bug#25421: http://bugs.mysql.com/25421)
* For mysql --show-warnings, warnings were in some cases not displayed.
(Bug#25146: http://bugs.mysql.com/25146)
* Using CREATE UNIQUE INDEX on a Falcon table where rows contain
duplicate values could result in pending transactions to the
table being deleted. (Bug#22842: http://bugs.mysql.com/22842)
* Creating a Falcon table with an auto-increment column that is not
indexed as the first column in a multi-column index would
auto0increment. This behavior was different to the behavior in both
MyISAM and InnoDB. Falcon now rejects such tables during creation in
the same way InnoDB does. (Bug#22564: http://bugs.mysql.com/22564)
* For storage engines that do not redefine handler::index_next_same()
and are capable of indexes, statements that include a WHERE clause
might select incorrect data. (Bug#22351: http://bugs.mysql.com/22351)
* Creating a new table or dropping a database on a newly created
database or tablespace where the Falcon engine was used would
raise an error. (Bug#22199: http://bugs.mysql.com/22199)
* Using TRUNCATE on a Falcon table did not reset the auto-increment
counters and used an inefficient method of deleting existing data.
(Bug#22173: http://bugs.mysql.com/22173)
* Creating a DATE outside the normal range within a Falcon table
would result in a zero DATE value being returned, even though
normally invalid values would be stored correctly in other
storage engines. (Bug#22168: http://bugs.mysql.com/22168)
* Selecting information from a Falcon table using a DOUBLE
column with an index would produce incorrect results.
(Bug#22125: http://bugs.mysql.com/22125)
* The readline library has been updated to version 5.2. This
addresses issues in the mysql client where history and editing
within the client would fail to work as expected.
(Bug#18431: http://bugs.mysql.com/18431)
* mysql stripped comments from statements sent to the server.
Now the --comments or --skip-comments option can be used to
control whether to retain or strip comments. The default is
--skip-comments. (Bug#11230: http://bugs.mysql.com/11230,
Bug#26215: http://bugs.mysql.com/26215)
* Executing DISABLE KEYS and ENABLE KEYS on a non-empty table would
cause the size of the index file for the table to grow considerably.
(Bug#4692: http://bugs.mysql.com/4692)
Enjoy,
Daniel
--
Daniel Fischer, Team Lead, Build +46 18174400 ext. 4537
MySQL GmbH, Dachauer Strasse 37, D-80335 Muenchen - http://www.mysql.com
Geschaeftsfuehrer: Kaj Arnoe HRB Muenchen 162140
Are you MySQL certified? mysql.com/certification 49.011, 8.376
MySQL 6.0.4-alpha, a new version of the MySQL database system including
the Falcon transactional storage engine (now at beta stage), has been
released. The main page for MySQL 6.0 is at:
http://www.mysql.com/mysql60/
If you are new to the Falcon storage engine and need more information,
please read the Falcon Evaluation Guide at:
http://www.mysql.com/why-mysql/white-papers/falcon-getting-started.php
and the Falcon White Paper at:
http://www.mysql.com/why-mysql/white-papers/storage-engines-falcon.php
MySQL 6.0.4-alpha is available in source and binary form for a number
of platforms from our download pages at
http://dev.mysql.com/downloads/mysql/6.0.html
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.
We welcome and appreciate your feedback, bug reports, bug fixes,
patches etc.:
http://forge.mysql.com/wiki/Contributing
Despite all trimming, describing all changes since the last released
version of MySQL 6.0 exceeds the mailing list configuration.
We had to split this message into two parts, this one (part 1) lists all
changes which are labeled "functionality", "security", "incompatible",
or "important".
You can view the full list online at
http://dev.mysql.com/doc/refman/6.0/en/news-6-0-4.html
"Functionality", "security", "incompatible", or "important" changes
since the last release:
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 partitioned tables.
(Bug#32091: http://bugs.mysql.com/32091, CVE-2007-5970
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5970))
See also Bug#29325: http://bugs.mysql.com/29325,
Bug#32111: http://bugs.mysql.com/32111
* Incompatible Change: The Unicode implementation has been
extended to provide support for supplementary characters that
lie outside the Basic Multilingual Plane (BMP). Noteworthy
features:
+ utf16 and utf32 character sets have been added. These correspond to
the UTF-16 and UTF-32 encodings of the Unicode character set, and
they both support supplementary characters.
+ The utf8 character set from previous versions of MySQL
has been renamed to utf8mb3, to reflect that its encoding
uses a maximum of three bytes for multi-byte characters.
(Old tables that previously used utf8 will be reported as
using utf8mb3 after an in-place upgrade to MySQL 6.0, but
otherwise work as before.)
+ The new utf8 character set in MySQL 6.0 is similar to
utf8mb3, but its encoding allows up to four bytes per
character to enable support for supplementary characters.
+ The ucs2 character set is essentially unchanged except
for the inclusion of some newer BMP characters.
In most respects, upgrading from MySQL 5.1 to 6.0 should
present few problems with regard to Unicode usage, although
there are some potential areas of incompatibility. Some
examples:
+ For the variable-length character data types (VARCHAR and
the TEXT types), the maximum length in characters for
utf8 columns is less in MySQL 6.0 than previously.
+ For all character data types (CHAR, VARCHAR, and the TEXT
types), the maximum number of characters for utf8 columns
that can be indexed is less in MySQL 6.0 than previously.
Consequently, if you want to upgrade tables from the old utf8
(now utf8mb3) to the current utf8, it may be necessary to
change some column or index definitions.
For additional details about the new Unicode character sets
and potential incompatibilities, see Section 9.1.8, "Unicode
Support," and Section 9.1.9, "Upgrading from Previous to
Current Unicode Support."
If you use events, a known issue is that if you upgrade from
MySQL 5.1 to 6.0.4, the event scheduler will not work, even
after you run mysql_upgrade. (This is an issue only for an
upgrade, not for a new installation of MySQL 6.0.4.) To work
around this upgrading problem, use these instructions:
1. In MySQL 5.1, before upgrading, create a dump file
containing your mysql.event table:
shell> mysqldump -uroot -p mysql event > event.sql
2. Stop the server, upgrade to MySQL 6.0, and start the server.
3. Recreate the mysql.event table using the dump file:
shell> mysql -uroot -p mysql < event.sql
4. Run mysql_upgrade to upgrade the other system tables in
the mysql database:
shell> mysql_upgrade -uroot -p
5. Restart the server. The event scheduler should run normally.
* Incompatible Change: Because of a change in the format of the
Falcon pages stored within Falcon database files, Falcon
databases created in MySQL 6.0.4 (or later) are not compatible
with previous releases, and existing Falcon databases are
incompatible with MySQL 6.0.4 (and later versions. You should
dump Falcon databases using mysqldump before upgrading, and
then reload them after the upgrade. For more information, see
Section 4.5.4, "mysqldump --- A Database Backup Program."
* Partitioning: Error messages for partitioning syntax errors
have been made more descriptive.
(Bug#29368: http://bugs.mysql.com/29368)
* Replication: Replication of the following now switches to row-based
logging in MIXED mode, and generates a warning in STATEMENT mode:
+ USER()
+ CURRENT_USER()
+ CURRENT_USER
+ FOUND_ROWS()
+ ROW_COUNT()
See Section 5.2.4.3, "Mixed Binary Logging (MBL) Format," for
more information. (Bug#12092: http://bugs.mysql.com/12092,
Bug#28086: http://bugs.mysql.com/28086,
Bug#30244: http://bugs.mysql.com/30244)
* Cluster Replication: A replication heartbeat mechanism has been added
to facilitate monitoring. This provides an alternative to checking log
files, making it possible to detect in real time when a slave has
failed. Configuration of heartbeats is done via a new
MASTER_HEARTBEAT_PERIOD = interval clause for the CHANGE MASTER TO
statement (see Section 12.6.2.1, "CHANGE MASTER TO Syntax");
monitoring can be done by checking the values of the status variables
Slave_heartbeat_period and Slave_received_heartbeats (see Section
5.1.5, "Status Variables").
The addition of replication heartbeats addresses a number of issues:
+ Relay logs were rotated every slave_net_timeout seconds
even if no statements were being replicated.
+ SHOW SLAVE STATUS displayed an incorrect value for
seconds_behind_master following a FLUSH LOGS statement.
+ Replication master-slave connections used
slave_net_timeout for connection timeouts.
(Bug#20435: http://bugs.mysql.com/20435,
Bug#29309: http://bugs.mysql.com/29309,
Bug#30932: http://bugs.mysql.com/30932)
* The --event-scheduler option without a value disabled the event
scheduler. Now it enables the event scheduler.
(Bug#31332: http://bugs.mysql.com/31332)
* 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 taken 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)
* 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. (Bug#28184: http://bugs.mysql.com/28184)
* It is now possible to set long_query_time in microseconds or to 0.
Setting this value to 0 causes all queries to be recorded in the slow
query log.
Currently, fractional values can be used only when logging to files.
We plan to provide this functionality for logging to tables when
time-related data types are enhanced to support microsecond
resolution. (Bug#25412: http://bugs.mysql.com/25412)
* INFORMATION_SCHEMA implementation changes were made that optimize
certain types of queries for INFORMATION_SCHEMA tables so that they
execute more quickly. Section 7.2.17, "INFORMATION_SCHEMA
Optimization," provides guidelines on how to take advantage of these
optimizations by writing queries that minimize the need for the server
to access the filesystem to obtain the information contained in
INFORMATION_SCHEMA tables. By writing queries that enable the server
to avoid directory scans or opening table files, you will obtain
better performance. (Bug#19588: http://bugs.mysql.com/19588)
* Three options were added to mysqldump make it easier to generate a
dump from a slave server. --dump-slave is similar to --master-data,
but the CHANGE MASTER statement contains binary log coordinates for
the slave's master host, not the slave itself.
--apply-slave-statements causes STOP SLAVE and START SLAVE statements
to be added before the CHANGE MASTER statement and at the end of the
output, respectively. --include-master-host-port causes the CHANGE
MASTER statement to include MASTER_PORT and MASTER_HOST options for
the slave's master. (Bug#8368: http://bugs.mysql.com/8368)
* An alternative thread model is available for dealing with the issues
that occur with the original one-thread-per-client model when scaling
to large numbers of simultaneous connections. This model uses thread
pooling:
+ Connection manager threads do not dedicate a thread to each client
connection. Instead, the connection is added to the set of existing
connection sockets. The server collects input from these sockets and
when a complete request has been received from a given client, it is
queued for service.
+ The server maintains a pool of service threads to process requests.
When a queued request is waiting and there is an available (not
busy) service thread in the pool, the request is given to the thread
to be handled. After processing the request, the service thread
becomes available to process other requests.
Service threads are created at server startup and exist until the
server terminates. A given service thread is not tied to a specific
client connection and the requests that it processes over time may
originate from different client connections.
+ The pool of service threads has a fixed size, so the amount of
memory required for it does not increase as the number of client
connections increases.
For information about choosing one thread model over the other and
tuning the parameters that control thread resources, see Section
7.5.7, "How MySQL Uses Threads for Client Connections."
* When the server detects MyISAM table corruption, it now writes
additional information to the error log, such as the name and
line number of the source file, and the list of threads accessing
the table. Example: Got an error from thread_id=1, mi_dynrec.c:368.
This is useful information to include in bug reports.
* Two options relating to slow query logging have been added for mysqld.
--log-slow-slave-statements causes slow statements executed by a
replication slave to be written to the slow query log;
in_examined_row_limit can be used to cause queries which examine fewer
than the stated number of rows not to be logged.
Bugs fixed:
* 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, CVE-2007-6313
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6313))
* 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 OpenSSL.
Note:
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
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0226),
CVE-2008-0227
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0227))
* 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 symlink points. 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
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=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. (Bug#29908: http://bugs.mysql.com/29908)
* 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. (Bug#29801: http://bugs.mysql.com/29801)
* Important Change: Incompatible Change: A number of problems
existed in the implementation of MERGE tables that could cause
problems. The problems are summarized below:
+ 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 hogging.
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 the server.
+ Bug#25038: http://bugs.mysql.com/25038 - Waiting TRUNCATE
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 TABLE
Repairing a child of an open MERGE table corrupted the child. It was
necessary to FLUSH the child first.
+ Bug#30275: http://bugs.mysql.com/30275 - MERGE tables:
FLUSH TABLES or UNLOCK TABLES causes server to crash.
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 non-MyISAM children.
+ 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 (errno: 155)".
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 Bug#19627: http://bugs.mysql.com/19627.
+ 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 table.
+ You cannot create a MERGE table with CREATE ... SELECT, neither as a
temporary MERGE table, nor as a non-temporary MERGE table. Example:
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...;
gives error message: table is not BASE TABLE.
(Bug#19627: http://bugs.mysql.com/19627,
Bug#25038: http://bugs.mysql.com/25038,
Bug#25700: http://bugs.mysql.com/25700,
Bug#26377: http://bugs.mysql.com/26377,
Bug#26379: http://bugs.mysql.com/26379,
Bug#26867: http://bugs.mysql.com/26867,
Bug#27660: http://bugs.mysql.com/27660,
Bug#30275: http://bugs.mysql.com/30275,
Bug#30491: http://bugs.mysql.com/30491)
* Incompatible Change: SET PASSWORD statements now cause an implicit
commit, and thus are prohibited within stored functions and triggers.
(Bug#30904: http://bugs.mysql.com/30904)
* 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: 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.
(Bug#20748: http://bugs.mysql.com/20748)
* 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.
(Bug#30695: http://bugs.mysql.com/30695)
MySQL 6.0.4-alpha, a new version of the MySQL database system including
the Falcon transactional storage engine (now at beta stage), has been
released. The main page for MySQL 6.0 is at:
http://www.mysql.com/mysql60/
If you are new to the Falcon storage engine and need more information,
please read the Falcon Evaluation Guide at:
http://www.mysql.com/why-mysql/white-papers/falcon-getting-started.php
and the Falcon White Paper at:
http://www.mysql.com/why-mysql/white-papers/storage-engines-falcon.php
MySQL 6.0.4-alpha is available in source and binary form for a number
of platforms from our download pages at
http://dev.mysql.com/downloads/mysql/6.0.html
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.
We welcome and appreciate your feedback, bug reports, bug fixes,
patches etc.:
http://forge.mysql.com/wiki/Contributing
Despite all trimming, describing all changes since the last released
version of MySQL 6.0 exceeds the mailing list configuration.
We had to split this message into two parts: part 1 (the other)
lists all changes which are labeled "functionality", "security",
"incompatible", or "important",
while this one lists the changes without such a label.
You can view the full list online at
http://dev.mysql.com/doc/refman/6.0/en/news-6-0-4.html
Changes since the last release:
...
Bugs fixed (part 2):
* Partitioning: MySQL Cluster: EXPLAIN PARTITIONS reported partition
usage by queries on NDB tables according to the standard MySQL hash
function than the hash function used in the NDB storage engine.
(Bug#29550: http://bugs.mysql.com/29550)
* 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,
Bug#30790: http://bugs.mysql.com/30790)
See also Bug#24231: http://bugs.mysql.com/24231,
Bug#30024: http://bugs.mysql.com/30024,
Bug#30133: http://bugs.mysql.com/30133,
Bug#30134: http://bugs.mysql.com/30134
* MySQL Cluster: An insert or update with combined range and equality
constraints failed when run against an NDB table with the error Got
unknown error from NDB. An example of such a statement would be UPDATE
t1 SET b = 5 WHERE a IN (7,8) OR a >= 10;.
(Bug#31874: http://bugs.mysql.com/31874)
* 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.
(Bug#31810: http://bugs.mysql.com/31810)
* MySQL Cluster: The NDB storage engine code was not safe for
strict-alias optimization in gcc 4.2.1.
(Bug#31761: http://bugs.mysql.com/31761)
* MySQL Cluster: Following an upgrade, ndb_mgmd would fail with
an ArbitratiDN_XSS_NEUTRALIZE_onError. (Bug#31690: http://bugs.mysql.com/31690)
* MySQL Cluster: It was possible in some cases for a node group to be
"lost" due to missed local checkpoints following a system restart.
(Bug#31525: http://bugs.mysql.com/31525)
* 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.
(Bug#31482: http://bugs.mysql.com/31482)
This regression was introduced by
Bug#29102: http://bugs.mysql.com/29102
* MySQL Cluster: NDB tables having names containing
non-alphanumeric characters (such as " $ ") were not
discovered correctly. (Bug#31470: http://bugs.mysql.com/31470)
* MySQL Cluster: A node failure during a local checkpoint could
lead to a subsequent failure of the cluster during a system
restart. (Bug#31257: http://bugs.mysql.com/31257)
* 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. (Bug#29509: http://bugs.mysql.com/29509)
* MySQL Cluster: An interpreted program of sufficient size and
complexity could cause all cluster data nodes to shut down due
to buffer overruns. (Bug#29390: http://bugs.mysql.com/29390)
* MySQL Cluster: Performing DELETE operations after a data node
had been shut down could lead to inconsistent data following a
restart of the node. (Bug#26450: http://bugs.mysql.com/26450)
* 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.
(Bug#25817: http://bugs.mysql.com/25817)
* MySQL Cluster: The cluster log was formatted inconsistently
and contained extraneous newline characters.
(Bug#25064: http://bugs.mysql.com/25064)
* MySQL Cluster: (Replication): Inconsistencies could occur
between the master and the slave when replicating Disk Data
tables. (Bug#19259: http://bugs.mysql.com/19259,
Bug#19227: http://bugs.mysql.com/19227)
* Partitioning: Repeated updates of a table that was partitioned
by KEY on a TIMESTAMP column eventually crashed the server.
(Bug#32067: http://bugs.mysql.com/32067)
* Partitioning: Selecting from a table partitioned by KEY on a
VARCHAR column whose size was greater than 65530 caused the
server to crash. (Bug#31705: http://bugs.mysql.com/31705)
* Partitioning: INSERT DELAYED into a partitioned table crashed
the server. (Bug#31201: http://bugs.mysql.com/31201)
* 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
Bug#27405: http://bugs.mysql.com/27405
* Partitioning: Falcon cannot drop a table for which there is a
pending transaction, but the error message for such attempts
was misleading. (Bug#22972: http://bugs.mysql.com/22972)
* 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 statement-based
replication. (Bug#32435: http://bugs.mysql.com/32435)
* 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.
(Bug#31836: http://bugs.mysql.com/31836)
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.
(Bug#31702: http://bugs.mysql.com/31702)
* 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.
(Bug#30752: http://bugs.mysql.com/30752)
* Replication: It was possible to set SQL_SLAVE_SKIP_COUNTER
such that the slave would jump into the middle of an event
group, including possibly a transaction.
(Bug#28618: http://bugs.mysql.com/28618)
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.
(Bug#28597: http://bugs.mysql.com/28597,
Bug#28603: http://bugs.mysql.com/28603)
See also Bug#31836: http://bugs.mysql.com/31836
This regression was introduced by
Bug#20166: http://bugs.mysql.com/20166
* Replication: Stored procedures having BIT parameters were not
replicated correctly. (Bug#26199: http://bugs.mysql.com/26199)
* Replication: Issuing SHOW SLAVE STATUS as mysqld was shutting
down could cause a crash.
(Bug#26000: http://bugs.mysql.com/26000)
* 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 executed
successfully. (Bug#24860: http://bugs.mysql.com/24860)
See also Bug#12691: http://bugs.mysql.com/12691,
Bug#23171: http://bugs.mysql.com/23171
* 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.
(Bug#21132: http://bugs.mysql.com/21132)
See also Bug#13963: http://bugs.mysql.com/13963,
Bug#21869: http://bugs.mysql.com/21869
* 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.
(Bug#19958: http://bugs.mysql.com/19958)
* 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. (Bug#33375: http://bugs.mysql.com/33375)
* Cluster Replication: A node failure during replication could
lead to buckets out of order; now active subscribers are
checked for, rather than empty buckets.
(Bug#31701: http://bugs.mysql.com/31701)
* Cluster Replication: In some cases, not all tables were
properly initialized before the binlog thread was started.
(Bug#31618: http://bugs.mysql.com/31618)
* Using Falcon when accessing multiple versions of the same
record, certain records could fail to be retrieved from the
record cache, causing an assertion failure.
(Bug#32862: http://bugs.mysql.com/32862)
* Creating an index on a Falcon table with a column using UTF32
that has been converted to UTF8 would cause a server crash.
(Bug#32833: http://bugs.mysql.com/32833)
* Using ALTER TABLE on a Falcon table it would be possible to
create two tables with the same name but different case.
(Bug#32830: http://bugs.mysql.com/32830)
* Converting a table from InnoDB to Falcon, where the Falcon
table with the same name (but different case) would cause a
server crash. (Bug#32829: http://bugs.mysql.com/32829)
* mysqld_safe looked for error messages in the wrong location.
(Bug#32679: http://bugs.mysql.com/32679)
* An issue with the NO_ENGINE_SUBSTITUTION sql_mode database can
cause the creation of stored routines to fail. If you are
having problems with creating stored routines while using this
sql_mode value, remove this value from your sql_mode setting.
(Bug#32633: http://bugs.mysql.com/32633)
* Repeatedly creating and dropping Falcon tablespaces would fail
because a dropped tablespace would not be dropped before the
new tablespace file was created.
(Bug#32621: http://bugs.mysql.com/32621)
* The INTERVAL() function incorrectly handled NULL values in the
value list. (Bug#32560: http://bugs.mysql.com/32560)
* Use of a NULL-returning GROUP BY expression in conjunction
with WITH ROLLUP could cause a server crash.
(Bug#32558: http://bugs.mysql.com/32558)
See also Bug#31095: http://bugs.mysql.com/31095
* ORDER BY UpdateXML(...) caused the server to crash in queries
where UpdateXML() returned NULL.
(Bug#32557: http://bugs.mysql.com/32557)
* Falcon used a fixed index key size which would be too small to
cope with some Falcon page sizes, leading to a crash. Falcon
now supports variable length index keys according to the
supported page sizes. See falcon_page_size.
(Bug#32554: http://bugs.mysql.com/32554)
* The rules for valid column names were being applied differently for
base tables and views. (Bug#32496: http://bugs.mysql.com/32496)
* Falcon options to set the limits of memory usage would not be
honoured. This could lead to crashes and assertions during
normal usage, instead of generating a suitable warning.
(Bug#32413: http://bugs.mysql.com/32413)
* Falcon would incorrectly return the supported repeatable-read
level when queried by the Online Backup system, preventing the
ability to create a consistent snapshot backup.
(Bug#32301: http://bugs.mysql.com/32301)
* Some uses of user variables in a query could result in a
server crash. (Bug#32260: http://bugs.mysql.com/32260)
* Under certain conditions, the presence of a GROUP BY clause
could cause an ORDER BY clause to be ignored.
(Bug#32202: http://bugs.mysql.com/32202)
* Altering a Falcon table to support an auto increment column on
a column with existing data and null values would incorrectly
update the table and return an incorrect count of the altered
rows. (Bug#32194: http://bugs.mysql.com/32194)
* InnoDB does not support SPATIAL indexes, but could crash when
asked to handle one. Now an error is returned.
(Bug#32125: http://bugs.mysql.com/32125)
* 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.
(Bug#32078: http://bugs.mysql.com/32078)
* Inserting, updating and deleting a large number of BLOB records in a
Falcon table would take significant amount of time and may prevent
shutdown. (Bug#32062: http://bugs.mysql.com/32062)
* On 64-bit platforms, assignments of values to enumeration-valued
storage engine-specific system variables were not validated and could
result in unexpected values. (Bug#32034: http://bugs.mysql.com/32034)
* A DELETE statement with a subquery in the WHERE clause would sometimes
ignore an error during subquery evaluation and proceed with the delete
operation. (Bug#32030: http://bugs.mysql.com/32030)
* 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.) (Bug#32021: http://bugs.mysql.com/32021)
* 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. (Bug#32020: http://bugs.mysql.com/32020)
* 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. (Bug#32007: http://bugs.mysql.com/32007)
* In debug builds, testing the result of an IN subquery against
NULL caused an assertion failure.
(Bug#31884: http://bugs.mysql.com/31884)
* SHOW CREATE TRIGGER caused a server crash.
(Bug#31866: http://bugs.mysql.com/31866)
* The server crashed after insertion of a negative value into an
AUTO_INCREMENT column of an InnoDB table.
(Bug#31860: http://bugs.mysql.com/31860)
* For libmysqld applications, handling of mysql_change_user()
calls left some pointers improperly updated, leading to server
crashes. (Bug#31850: http://bugs.mysql.com/31850)
* 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'.
(Bug#31800: http://bugs.mysql.com/31800)
* 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. (Bug#31794: http://bugs.mysql.com/31794)
* The server could crash during filesort for ORDER BY based on
expressions with INET_NTOA() or OCT() if those functions
returned NULL. (Bug#31758: http://bugs.mysql.com/31758)
* 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. (Bug#31742: http://bugs.mysql.com/31742)
* The examined-rows count was not incremented for const queries.
(Bug#31700: http://bugs.mysql.com/31700)
* Falcon tables would fail during replication if ROW-based
replication was specified. (Bug#31671: http://bugs.mysql.com/31671)
* 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)
* For queries for which loose index scan is applicable, the
optimizer could choose the wrong execution plan for correlated
subqueries. (Bug#31639: http://bugs.mysql.com/31639)
* 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.
(Bug#31630: http://bugs.mysql.com/31630)
* A buffer used when setting variables was not dimensioned to
accommodate the trailing '\0' byte, so a single-byte buffer
overrun was possible. (Bug#31588: http://bugs.mysql.com/31588)
* For semi-join processing, pullout of functionally dependent
tables was not handled transitively.
(Bug#31563: http://bugs.mysql.com/31563)
* HAVING could treat lettercase of table aliases incorrectly if
lower_case_table_names was enabled.
(Bug#31562: http://bugs.mysql.com/31562)
* 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)
* When inserting dates into a DATETIME column with a Falcon, the
values would automatically be converted with values between 70
and 99 converted to 1970-1999, and values from 00 to 69
converted to 2000 to 2069. These dates are now correctly
handled. (Bug#31490: http://bugs.mysql.com/31490)
* The length of the result from IFNULL() could be calculated
incorrectly because the sign of the result was not taken into
account. (Bug#31471: http://bugs.mysql.com/31471)
* 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.
(Bug#31450: http://bugs.mysql.com/31450)
* 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.
(Bug#31444: http://bugs.mysql.com/31444)
* SELECT 1 REGEX NULL caused an assertion failure for debug
servers. (Bug#31440: http://bugs.mysql.com/31440)
* INFORMATION_SCHEMA.TABLES was returning incorrect information.
(Bug#31381: http://bugs.mysql.com/31381)
* DROP USER caused an increase in memory usage.
(Bug#31347: http://bugs.mysql.com/31347)
* TABLESPACE names within Falcon did not support characters
outside the alpha-numeric ASCII character set.
(Bug#31311: http://bugs.mysql.com/31311)
* For InnoDB tables with READ COMMITTED isolation level, UPDATE
statements skipped rows locked by another transaction, rather
than waiting for the locks to be released.
(Bug#31310: http://bugs.mysql.com/31310)
* For an almost-full MyISAM table, an insert that failed could
leave the table in a corrupt state.
(Bug#31305: http://bugs.mysql.com/31305)
* When dropping Falcon tablespaces the associated tablespace
file would not be deleted. (Bug#31296: http://bugs.mysql.com/31296)
* myisamchk --unpack could corrupt a table that when unpacked has static
(fixed-length) row format. (Bug#31277: http://bugs.mysql.com/31277)
* Building a 64-bit binary with support for the Falcon storage
engine using gcc on Solaris could fail. See Section 2.9,
"MySQL Installation Using a Source Distribution," for more
information. (Bug#31268: http://bugs.mysql.com/31268,
Bug#33126: http://bugs.mysql.com/33126)
* When a TIMESTAMP with a non-zero time part was converted to a
DATE value, no warning was generated. This caused index
lookups to assume that this is a valid conversion and was
returning rows that match a comparison between a TIMESTAMP
value and a DATE keypart. Now a warning is generated so that
TIMESTAMP with a non-zero time part will not match DATE
values. (Bug#31221: http://bugs.mysql.com/31221)
* If MAKETIME() returned NULL when used in an ORDER BY that was
evaluated using filesort, a server crash could result.
(Bug#31160: http://bugs.mysql.com/31160)
* LAST_INSERT_ID() execution could be handled improperly in
subqueries. (Bug#31157: http://bugs.mysql.com/31157)
* An assertion designed to detect a bug in the ROLLUP implementation
would incorrectly be triggered when used in a subquery context with
non-cacheable statements. (Bug#31156: http://bugs.mysql.com/31156)
* When creating a TABLESPACE that uses the same name as an existing
TABLESPACE, Falcon would return Unknown error -103. MySQL will now
return an error stating that the specified tablespace already exists.
(Bug#31114: http://bugs.mysql.com/31114)
* mysqldump failed to handle databases containing a `-' character
in the name. (Bug#31113: http://bugs.mysql.com/31113)
* Starting the server using --read-only and with the Event Scheduler
enabled caused it to crash. (Bug#31111: http://bugs.mysql.com/31111)
* Dropping a tablespace and specifying an engine type that does not
support tablespaces would report a warning. The response has now been
updated to report an error. (Bug#31110: http://bugs.mysql.com/31110)
* GROUP BY NULL WITH ROLLUP could cause a server crash.
(Bug#31095: http://bugs.mysql.com/31095)
See also Bug#32558: http://bugs.mysql.com/32558
* A rule to prefer filesort over an indexed ORDER BY when
accessing all rows of a table was being used even if a LIMIT
clause was present. (Bug#31094: http://bugs.mysql.com/31094)
* REGEXP operations could cause a server crash for character sets such
as ucs2. Now the arguments are converted to utf8 if possible, to allow
correct results to be produced if the resulting strings contain only
8-bit characters. (Bug#31081: http://bugs.mysql.com/31081)
* Expressions of the form WHERE col NOT IN (col, ...), where the
same column was named both times, could cause a server crash
in the optimizer. (Bug#31075: http://bugs.mysql.com/31075)
* Falcon would fail to compile on FreeBSD. This limitation has
now been fixed. (Bug#31045: http://bugs.mysql.com/31045)
* Using ORDER BY with ARCHIVE tables caused a server crash.
(Bug#31036: http://bugs.mysql.com/31036)
* The MOD() function and the % operator crashed the server for a
divisor less than 1 with a very long fractional part.
(Bug#31019: http://bugs.mysql.com/31019)
* Using falcon_serial_log_dir to set the location of the Falcon
serial log would have no effect.
(Bug#31005: http://bugs.mysql.com/31005)
* The LooseScan subquery optimization strategy could produce
duplicate rows in query results.
(Bug#30993: http://bugs.mysql.com/30993)
* A character set introducer followed by a hexadecimal or bit-value
literal did not check its argument and could return an ill-formed
result for invalid input. (Bug#30986: http://bugs.mysql.com/30986)
* CHAR(str USING charset) did not check its argument and could
return an ill-formed result for invalid input.
(Bug#30982: http://bugs.mysql.com/30982)
* The result from CHAR(str USING ucs2) did not add a leading
0x00 byte for input strings with an odd number of bytes.
(Bug#30981: http://bugs.mysql.com/30981)
* A cluster restart could sometimes fail due to an issue with
table IDs. (Bug#30975: http://bugs.mysql.com/30975)
* The GeomFromText() function could cause a server crash if the
first argument was NULL or the empty string.
(Bug#30955: http://bugs.mysql.com/30955)
* When invoked with constant arguments, STR_TO_DATE() could use
a cached value for the format string and return incorrect
results. (Bug#30942: http://bugs.mysql.com/30942)
* GROUP_CONCAT() returned ',' rather than an empty string when
the argument column contained only empty strings.
(Bug#30897: http://bugs.mysql.com/30897)
* A server crash could occur if a stored function that contained
a DROP TEMPORARY TABLE statement was invoked by a CREATE
TEMPORARY TABLE statement that created a table of the same
name. (Bug#30882: http://bugs.mysql.com/30882)
* Calling NAME_CONST() with non-constant arguments triggered an
assertion failure. Non-constant arguments are now disallowed.
(Bug#30832: http://bugs.mysql.com/30832)
* Running ALTER TABLE ... OPTIMIZE PARTITION on a Falcon table,
a 'divide by zero' error would be reported during a server
crash. (Bug#30826: http://bugs.mysql.com/30826)
* For a spatial column with a regular (non-SPATIAL) index,
queries failed if the optimizer tried to use the index.
(Bug#30825: http://bugs.mysql.com/30825)
* INFORMATION_SCHEMA.SCHEMATA was returning incorrect information.
(Bug#30795: http://bugs.mysql.com/30795)
* On Windows, the pthread_mutex_trylock() implementation was incorrect.
One symptom was that invalidating the query cache could cause a server
crash. (Bug#30768: http://bugs.mysql.com/30768)
* A multiple-table UPDATE involving transactional and non-transactional
tables caused an assertion failure.
(Bug#30763: http://bugs.mysql.com/30763)
* Under some circumstances, CREATE TABLE ... SELECT could crash
the server or incorrectly report that the table row size was
too large. (Bug#30736: http://bugs.mysql.com/30736)
* Using the MIN() or MAX() function to select one part of a
multi-part key could cause a crash when the function result
was NULL. (Bug#30715: http://bugs.mysql.com/30715)
* INFORMATION_SCHEMA.VIEWS.VIEW_DEFINITION was incorrect for views that
were defined to select from other INFORMATION_SCHEMA tables.
(Bug#30689: http://bugs.mysql.com/30689)
* Issuing an ALTER SERVER statement to update the settings for a
FEDERATED server would cause the mysqld to crash.
(Bug#30671: http://bugs.mysql.com/30671)
* The optimizer could ignore ORDER BY in cases when the result
set is ordered by filesort, resulting in rows being returned
in incorrect order. (Bug#30666: http://bugs.mysql.com/30666)
* A different execution plan was displayed for EXPLAIN than
would actually have been used for the SELECT because the test
of sort keys for ORDER BY did not consider keys mentioned in
IGNORE KEYS FOR ORDER BY.
(Bug#30665: http://bugs.mysql.com/30665)
* MyISAM tables could not exceed 4294967295 (2^32 - 1) rows on
Windows. (Bug#30638: http://bugs.mysql.com/30638)
* mysql-test-run.pl could not run mysqld with root privileges.
(Bug#30630: http://bugs.mysql.com/30630)
* Using GROUP BY on an expression of the form timestamp_col DIV
number caused a server crash due to incorrect calculation of
number of decimals. (Bug#30587: http://bugs.mysql.com/30587)
* The options available to the CHECK TABLE statement were also
allowed in OPTIMIZE TABLE and ANALYZE TABLE statements, but
caused corruption during their execution. An error is now
raised if you try to apply these options to these statements.
(Bug#30495: http://bugs.mysql.com/30495)
* When expanding a * in a USING or NATURAL join, the check for
table access for both tables in the join was done using only
the grant information of the first table.
(Bug#30468: http://bugs.mysql.com/30468)
* Compared to MySQL 5.1, the 6.0 optimizer failed to use join
buffering for certain queries, resulting in slower performance
for those queries. (Bug#30363: http://bugs.mysql.com/30363)
* A table-access check was performed improperly by libmysqld,
causing a crash. (Bug#30329: http://bugs.mysql.com/30329)
* Some valid euc-kr characters having the second byte in the
ranges [0x41..0x5A] and [0x61..0x7A] were rejected.
(Bug#30315: http://bugs.mysql.com/30315)
* When loading a dynamic plugin on FreeBSD, the plugin would fail to
load. This was due to a build error where the required symbols would
be not exported correctly. (Bug#30296: http://bugs.mysql.com/30296)
* Setting certain values on a table using a spatial index could cause
the server to crash. (Bug#30286: http://bugs.mysql.com/30286)
* Some INFORMATION_SCHEMA tables are intended for internal use, but
could be accessed by using SHOW statements.
(Bug#30079: http://bugs.mysql.com/30079)
* On some 64-bit systems, inserting the largest negative value into a
BIGINT column resulted in incorrect data.
(Bug#30069: http://bugs.mysql.com/30069)
* mysqlslap did not properly handle multiple result sets from
stored procedures. (Bug#29985: http://bugs.mysql.com/29985)
* Running the sqlbench test suite against Falcon would cause a
crash. (Bug#29870: http://bugs.mysql.com/29870)
* When accessing statistics in INFORMATION_SCHEMA.FALCON_DATABASE_IO,
the information would relate only to the Falcon database, not user
tablespaces. (Bug#29823: http://bugs.mysql.com/29823)
* Whitespace characters other than spaces within XML tags, such
as linefeeds or tabs, caused LOAD XML INFILE to skip rows.
(Bug#29752: http://bugs.mysql.com/29752)
* configure did not find nss on some Linux platforms.
(Bug#29658: http://bugs.mysql.com/29658)
* Compilation failed on systems where a native log2() implementation was
unavailable. (Bug#29640: http://bugs.mysql.com/29640)
* Use of the latin2_czech_cs collation caused a server crash.
(Bug#29459: http://bugs.mysql.com/29459)
* Using two simultaneous connections it was possible to create a
deadlock situation between two different active transactions on the
same Falcon table. There is no way to prevent this, but a new
parameter, falcon_lock_timeout can set the timeout for deadlocked
transactions. The default timeout is 0 (timeouts are disabled).
(Bug#29452: http://bugs.mysql.com/29452)
* The mysql client program now ignores Unicode byte order mark
(BOM) characters at the beginning of input files. Previously,
it read them and sent them to the server, resulting in a
syntax error. (Bug#29323: http://bugs.mysql.com/29323)
* Insert information into the same table from multiple threads could
cause duplicate key errors. This was related to the changes made to
allow compatibility with the InnoDB repeatable-read isolation level.
The option, falcon_innodb_compatibility, has been renamed to
falcon_consistent_read, but with the opposite effect. The default is
for this option to be on. When set to off, the behaviour of Falcon is
similar to that in InnoDB. (Bug#29151: http://bugs.mysql.com/29151)
* For transactional tables, an error during a multiple-table DELETE
statement did not roll back the statement.
(Bug#29136: http://bugs.mysql.com/29136)
* The log and log_slow_queries system variables were displayed by SHOW
VARIABLES but could not be accessed in expressions as @@log and
@@log_slow_queries. (Bug#29131: http://bugs.mysql.com/29131)
* When loading large data sets using LOAD DATA INFILE into a Falcon
table, the server could crash.
(Bug#29081: http://bugs.mysql.com/29081)
* SHOW VARIABLES did not display the relay_log, relay_log_index,
or relay_log_info_file system variables.
(Bug#28893: http://bugs.mysql.com/28893)
* Index hints specified in view definitions were ignored when using the
view to select from the base table.
(Bug#28702: http://bugs.mysql.com/28702)
* Views do not have indexes, so index hints do not apply. Use of
index hints when selecting from a view is now disallowed.
(Bug#28701: http://bugs.mysql.com/28701)
* After changing the SQL mode to a restrictive value that would
make already-inserted dates in a column be considered invalid,
searches returned different results depending on whether the
column was indexed. (Bug#28687: http://bugs.mysql.com/28687)
* The result from CHAR() was incorrectly assumed in some contexts to
return a single-byte result. (Bug#28550: http://bugs.mysql.com/28550)
* Using a temporary table within Falcon that is created in a
directory where the path contains a mixture of upper and lower
letters would fail. (Bug#28541: http://bugs.mysql.com/28541)
* Under heavy load when updating Falcon tables, a race condition
could occur that would ultimately result in a crash.
(Bug#28519: http://bugs.mysql.com/28519)
* The result of a comparison between VARBINARY and BINARY
columns differed depending on whether the VARBINARY column was
indexed. (Bug#28076: http://bugs.mysql.com/28076)
* The metadata in some MYSQL_FIELD members could be incorrect
when a temporary table was used to evaluate a query.
(Bug#27990: http://bugs.mysql.com/27990)
* It was possible to create a view having a column whose name
consisted of an empty string or space characters only.
(Bug#27695: http://bugs.mysql.com/27695)
See also Bug#31202: http://bugs.mysql.com/31202
* ALTER TABLE tbl_name ROW_FORMAT=format_type did not cause the
table to be rebuilt. (Bug#27610: http://bugs.mysql.com/27610)
* Searching a Falcon table that uses DATETIME columns with an index
could return incorrect results.
(Bug#27426: http://bugs.mysql.com/27426)
* Removing a partition on a Falcon table when there are two
tables with the same name, but different case, would cause a
crash during normal shutdown. (Bug#27425: http://bugs.mysql.com/27425)
* Mixing differently cased tables between MyISAM and Falcon
tables would cause a crash. (Bug#27424: http://bugs.mysql.com/27424)
* The ExtractValue() and UpdateXML() functions performed extremely
slowly for large amounts of XML data (greater than 64 KB). These
functions now execute approximately 2000 times faster than previously.
(Bug#27287: http://bugs.mysql.com/27287)
* On Windows, writes to the debug log were using freopen() instead of
fflush(), resulting in slower performance.
(Bug#27099: http://bugs.mysql.com/27099)
* Connections from one mysqld server to another failed on Mac OS X,
affecting replication and FEDERATED tables.
(Bug#26664: http://bugs.mysql.com/26664)
See also Bug#29083: http://bugs.mysql.com/29083
* LOAD DATA INFILE ran very slowly when reading large files into
partitioned tables. (Bug#26527: http://bugs.mysql.com/26527)
* 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 EXPLAIN), the query in the
statistics state (shown by the SHOW PROCESSLIST) did not respond to
the KILL statement. (Bug#25421: http://bugs.mysql.com/25421)
* For mysql --show-warnings, warnings were in some cases not displayed.
(Bug#25146: http://bugs.mysql.com/25146)
* Using CREATE UNIQUE INDEX on a Falcon table where rows contain
duplicate values could result in pending transactions to the
table being deleted. (Bug#22842: http://bugs.mysql.com/22842)
* Creating a Falcon table with an auto-increment column that is not
indexed as the first column in a multi-column index would
auto0increment. This behavior was different to the behavior in both
MyISAM and InnoDB. Falcon now rejects such tables during creation in
the same way InnoDB does. (Bug#22564: http://bugs.mysql.com/22564)
* For storage engines that do not redefine handler::index_next_same()
and are capable of indexes, statements that include a WHERE clause
might select incorrect data. (Bug#22351: http://bugs.mysql.com/22351)
* Creating a new table or dropping a database on a newly created
database or tablespace where the Falcon engine was used would
raise an error. (Bug#22199: http://bugs.mysql.com/22199)
* Using TRUNCATE on a Falcon table did not reset the auto-increment
counters and used an inefficient method of deleting existing data.
(Bug#22173: http://bugs.mysql.com/22173)
* Creating a DATE outside the normal range within a Falcon table
would result in a zero DATE value being returned, even though
normally invalid values would be stored correctly in other
storage engines. (Bug#22168: http://bugs.mysql.com/22168)
* Selecting information from a Falcon table using a DOUBLE
column with an index would produce incorrect results.
(Bug#22125: http://bugs.mysql.com/22125)
* The readline library has been updated to version 5.2. This
addresses issues in the mysql client where history and editing
within the client would fail to work as expected.
(Bug#18431: http://bugs.mysql.com/18431)
* mysql stripped comments from statements sent to the server.
Now the --comments or --skip-comments option can be used to
control whether to retain or strip comments. The default is
--skip-comments. (Bug#11230: http://bugs.mysql.com/11230,
Bug#26215: http://bugs.mysql.com/26215)
* Executing DISABLE KEYS and ENABLE KEYS on a non-empty table would
cause the size of the index file for the table to grow considerably.
(Bug#4692: http://bugs.mysql.com/4692)
Enjoy,
Daniel
--
Daniel Fischer, Team Lead, Build +46 18174400 ext. 4537
MySQL GmbH, Dachauer Strasse 37, D-80335 Muenchen - http://www.mysql.com
Geschaeftsfuehrer: Kaj Arnoe HRB Muenchen 162140
Are you MySQL certified? mysql.com/certification 49.011, 8.376
