Skip navigation links

Additional languages
C.1.4 Changes in MySQL 6.0.3 (16 November 2007) »
Section Navigation      [Toggle]

C.1.3. Changes in MySQL 6.0.4 (12 February 2008)

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, CVE-2007-5970)

    See also Bug#29325, Bug#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”.

  • MySQL Cluster: Introduced the Ndb_execute_count status variable, which measures the number of round trips made by queries to the NDB kernel.

  • Partitioning: Error messages for partitioning syntax errors have been made more descriptive. (Bug#29368)

  • Cluster Replication: 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.6, “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, Bug#29309, Bug#30932)

  • Replication: Replication of the following SQL functions now switches to row-based logging in MIXED mode, and generates a warning in STATEMENT mode:

    See Section 5.2.4.3, “Mixed Binary Logging Format”, for more information. (Bug#12092, Bug#28086, Bug#30244)

  • The (undocumented) configure script previously included with binary distributions is no longer included. (Bug#35011)

  • The --event-scheduler option without a value disabled the event scheduler. Now it enables the event scheduler. (Bug#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 take at different times to appear to be different. The new options --dump-date and --skip-dump-date control whether the date is added to the comment. --skip-dump-date suppresses date printing. The default is --dump-date (include the date in the comment). (Bug#31077)

  • 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)

  • Added the --auto-vertical-output option to mysql which causes result sets to be displayed vertically if they are too wide for the current window, and using normal tabular format otherwise. (This applies to statements terminated by ; or \G.) (Bug#26780)

  • 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)

  • 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.20, “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)

  • 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)

  • 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; min_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, 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, CVE-2008-0226, 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, 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)

  • 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)

  • 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 - 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 - 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 - 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 - 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 - 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 - MERGE tables: FLUSH TABLES or UNLOCK TABLES causes server to crash.

      Flushing and optimizing locked MERGE children crashed the server.

    • Bug#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 - Falcon: MERGE table possible

      It was possible to create a MERGE table with non-MyISAM children.

    • Bug#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.

    • 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. For example, CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...; causes the error message: table is not BASE TABLE.

    (Bug#19627, Bug#25038, Bug#25700, Bug#26377, Bug#26379, Bug#26867, Bug#27660, Bug#30275, Bug#30491)

  • Incompatible Change: The falcon_lock_timeout system variable, which had a value in milliseconds, has been replaced with falcon_lock_wait_timeout, which has a value in seconds. The default value of falcon_lock_wait_timeout is 50 seconds. This has been done for better name and unit consistency with the innodb_lock_wait_timeout system variable. Uses of the old variable should be converted to use the new variable. (Bug#33474, Bug#33072)

  • Incompatible Change: 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.

    This bugfix results in the following behavior:

    • There is a check against mixing group and non-group columns only when ONLY_FULL_GROUP_BY is enabled.

    • This check is done both for the select list and for the HAVING clause if there is one.

    This behavior differs from previous versions as follows:

    • Previously, the HAVING clause was not checked when ONLY_FULL_GROUP_BY was enabled; now it is checked.

    • Previously, the select list was checked even when ONLY_FULL_GROUP_BY was not enabled; now it is checked only when ONLY_FULL_GROUP_BY is enabled.

    (Bug#31794)

  • Incompatible Change: SET PASSWORD statements now cause an implicit commit, and thus are prohibited within stored functions and triggers. (Bug#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)

  • 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.

    The fix for this problem had a side effect such that on Unix, MySQL programs looked for options in ~/my.cnf rather than the standard location of ~/.my.cnf. That problem was addressed as Bug#38180. (Bug#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.

    Note

    Upgrading to the current (or later) release solves this problem only for tables that are newly created or altered. Tables created or altered in previous versions of the server to include ' characters in PARTITION options must still be removed by deleting the corresponding .FRM files and re-creating them afterwards.

    (Bug#30695)

  • 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)

  • 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, Bug#30790)

    See also Bug#24231, Bug#30024, Bug#30133, Bug#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)

  • 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)

  • MySQL Cluster: The NDB storage engine code was not safe for strict-alias optimization in gcc 4.2.1. (Bug#31761)

  • MySQL Cluster: Following an upgrade, ndb_mgmd would fail with an ArbitrationError. (Bug#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)

  • 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)

    This regression was introduced by Bug#29102

  • MySQL Cluster: NDB tables having names containing non-alphanumeric characters (such as “ $ ”) were not discovered correctly. (Bug#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)

  • MySQL Cluster: A cluster restart could sometimes fail due to an issue with table IDs. (Bug#30975)

  • MySQL Cluster: In some cases, the cluster managment server logged entries multiple times following a restart of mgmd. (Bug#29565)

  • MySQL Cluster: ndb_mgm --help did not display any information about the -a option. (Bug#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)

  • 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)

  • 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)

  • MySQL Cluster: The cluster log was formatted inconsistently and contained extraneous newline characters. (Bug#25064)

  • MySQL Cluster: (Replication): Inconsistencies could occur between the master and the slave when replicating Disk Data tables. (Bug#19259, Bug#19227)

  • Partitioning: Repeated updates of a table that was partitioned by KEY on a TIMESTAMP column eventually crashed the server. (Bug#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)

  • Partitioning: INSERT DELAYED on a partitioned table crashed the server. The server now rejects the statement with an error. (Bug#31210)

  • Partitioning: Using ALTER TABLE to partition an existing table having an AUTO_INCREMENT column could crash the server. (Bug#30878)

    This regression was introduced by Bug#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)

  • Replication: When using a transactional storage engine not using statement-based logging, a duplicate key error on the master caused replication to fail. This issue was first observed when using the Falcon storage engine. (Bug#33688)

  • 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)

  • 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)

    See also Bug#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)

  • Replication: Trying to replicate an update of a row that was missing on the slave led to a failure on the slave. (Bug#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)

  • 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)

  • 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)

    See also Bug#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, Bug#28603)

    See also Bug#31836

    This regression was introduced by Bug#20166

  • Replication: Stored procedures having BIT parameters were not replicated correctly. (Bug#26199)

  • Replication: Issuing SHOW SLAVE STATUS as mysqld was shutting down could cause a crash. (Bug#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)

    See also Bug#12691, Bug#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)

    See also Bug#12713

  • Replication: A replication slave sometimes failed to reconnect because it was unable to run SHOW SLAVE HOSTS. It was not necessary to run this statement on slaves (since the master should track connection IDs), and the execution of this statement by slaves was removed. (Bug#21132)

    See also Bug#13963, Bug#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)

  • 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)

  • 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)

  • Cluster Replication: Replicating NDB tables with extra VARCHAR columns on the master caused the slave to fail. (Bug#31646)

    See also Bug#29549

  • Cluster Replication: In some cases, not all tables were properly initialized before the binlog thread was started. (Bug#31618)

  • Cluster API: A buffer overrun in NdbBlob::setValue() caused erroneous results on Mac OS X. (Bug#31284)

  • Setting falcon_consistent_read to a value of 1 or ON resulted in a value of –1 being assigned. (Bug#34331)

  • Compiling MySQL on FreeBSD would fail due to missing definitions for certain network constants. (Bug#34292)

  • The INFORMATION_SCHEMA.FALCON_TRANSACTIONS had two columns named STATE. (Bug#34241)

  • For Falcon, under some circumstances, a rolled back record could appear not to be removed. (Bug#34174)

  • Attempting to set the isolation level to a value not supported by Falcon caused a Falcon assertion failure. (Bug#34164)

  • Falcon did not compile on Mac OS X/Intel or Mac OS X/PPC. (Bug#34095)

  • When inserting very large data sets into table using INSERT INTO ... SELECT FROM on a Falcon table when the value of falcon_page_cache_size is higher than the available memory. Instead of returning an error, mysqld would crash in this instance. (Bug#34086)

  • For Falcon, an initializing transaction created a dependency on a commitNoUpdate transaction releasing transaction dependencies, which caused an assertion failure. (Bug#33759)

  • The output from SHOW CREATE TABLE on a Falcon table would not include the AUTO_INCREMENT value parameters. (Bug#33662)

  • An INSERT into a Falcon table with partitions and an auto-increment column would fail. (Bug#33661)

  • For table creation, Falcon did not handle identifiers with embedded double quotes. (Bug#33657, Bug#33667)

  • Contention between concurrent Falcon transactions could cause some queries to be starved for a long time. (Bug#33634)

  • Incomplete Falcon recovery after server restarts eventually resulted in tablespace corruption. (Bug#33608, Bug#33665)

  • Using falcon_debug_mask to enable debugging messages could lead to some messages not being correctly flushed to the log file. (Bug#33531)

  • After a server restart, Falcon mishandled metadata, resulting in apparent corruption of BLOB data. (Bug#33492)

  • Multiple simultaneous inserts into a partitioned Falcon table could deadlock. (Bug#33480)

  • Dropping a tablespace for the Falcon storage engine when the specified tablespace did not exist would silently succeed, instead of generating a suitable error message. (Bug#33212)

  • Multiple concurrent delete operations on a Falcon table were serialized rather than executing concurrently, resulting in poor performance. (Bug#33191)

  • Inserting millions of rows into a Falcon table could cause the insert operation to hang. (Bug#33175)

  • Using ALTER TABLE to convert a CHAR column using the ucs2 character set to VARBINARY when using a Falcon table would cause a crash. (Bug#33081)

  • Multiple Falcon gopher threads attempting to update the same index could result in failure to add new index entries. (Bug#33080)

  • Falcon tried to delete a record from an empty record locator page, which could cause a server crash. (Bug#33068)

  • When updating columns for a row when using a Falcon table, the values for columns that were not updated were replicated as NULL. (Bug#33055)

  • Falcon failed to rebuild a Section page during recovery, causing a server crash. (Bug#32921)

  • 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)

  • 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)

  • Using ALTER TABLE on a Falcon table it would be possible to create two tables with the same name but different case. (Bug#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)

  • Concurrent TRUNCATE TABLE operations for Falcon tables caused Falcon to crash. (Bug#32730)

  • mysqld_safe looked for error messages in the wrong location. (Bug#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)

  • Repeatedly creating and dropping Falcon tablespaces failed because the old tablespace was not dropped before the new tablespace file was created. (Bug#32621)

  • Falcon did not properly handle quoted column name or tablespace name identifiers. (Bug#32620)

  • The INTERVAL() function incorrectly handled NULL values in the value list. (Bug#32560)

  • Use of a NULL-returning GROUP BY expression in conjunction with WITH ROLLUP could cause a server crash. (Bug#32558)

    See also Bug#31095

  • ORDER BY UpdateXML(...) caused the server to crash in queries where UpdateXML() returned NULL. (Bug#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)

  • The rules for valid column names were being applied differently for base tables and views. (Bug#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)

  • 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)

  • Some uses of user variables in a query could result in a server crash. (Bug#32260)

  • Under certain conditions, the presence of a GROUP BY clause could cause an ORDER BY clause to be ignored. (Bug#32202)

  • On Mac OS X, creating a Falcon table using a new Falcon installation caused a crash. (Bug#32201)

  • 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)

  • DELETE FROM tbl_name (no WHERE clause) for a Falcon table caused replication to fail on the slave. (Bug#32150)

  • InnoDB does not support SPATIAL indexes, but could crash when asked to handle one. Now an error is returned. (Bug#32125)

  • The server crashed on optimizations involving a join of INT and MEDIUMINT columns and a system variable in the WHERE clause. (Bug#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)

  • 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)

  • 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)

  • 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)

  • 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)

  • 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)

  • 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)

  • In debug builds, testing the result of an IN subquery against NULL caused an assertion failure. (Bug#31884)

  • SHOW CREATE TRIGGER caused a server crash. (Bug#31866)

  • The server crashed after insertion of a negative value into an AUTO_INCREMENT column of an InnoDB table. (Bug#31860)

  • For libmysqld applications, handling of mysql_change_user() calls left some pointers improperly updated, leading to server crashes. (Bug#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'. BETWEEN treated the values as DATETIME, whereas the other operators performed a binary-string comparison. Now they all uniformly use a DATETIME comparison, but generate warnings for values with trailing garbage. (Bug#31800)

  • The server could crash during filesort for ORDER BY based on expressions with INET_NTOA() or OCT() if those functions returned NULL. (Bug#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)

  • The examined-rows count was not incremented for const queries. (Bug#31700)

  • Falcon tables would fail during replication if ROW-based replication was specified. (Bug#31671)

  • The mysql_change_user() C API function was subject to buffer overflow. (Bug#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)

  • 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)

  • The mysqlbug script did not include the correct values of CFLAGS and CXXFLAGS that were used to configure the distribution. (Bug#31644)

  • For queries for which loose index scan is applicable, the optimizer could choose the wrong execution plan for correlated subqueries. (Bug#31639)

  • Queries that include a comparison of an INFORMATION_SCHEMA table column to NULL caused a server crash. (Bug#31633)

  • EXPLAIN EXTENDED for SELECT from INFORMATION_SCHEMA tables caused an assertion failure. (Bug#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)

  • For semi-join processing, pullout of functionally dependent tables was not handled transitively. (Bug#31563)

  • HAVING could treat lettercase of table aliases incorrectly if lower_case_table_names was enabled. (Bug#31562)

  • Spurious duplicate-key errors could occur for multiple-row inserts into an InnoDB table that activate a trigger. (Bug#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)

  • The length of the result from IFNULL() could be calculated incorrectly because the sign of the result was not taken into account. (Bug#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)

  • 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)

  • SELECT 1 REGEX NULL caused an assertion failure for debug servers. (Bug#31440)

  • INFORMATION_SCHEMA.TABLES was returning incorrect information. (Bug#31381)

  • DROP USER caused an increase in memory usage. (Bug#31347)

  • mysql_install_db failed if the default storage engine was NDB. Now it explicitly uses MyISAM as the storage engine when running mysqld --bootstrap. (Bug#31315)

  • TABLESPACE names within Falcon did not support characters outside the alpha-numeric ASCII character set. (Bug#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)

  • For an almost-full MyISAM table, an insert that failed could leave the table in a corrupt state. (Bug#31305)

  • When dropping Falcon tablespaces the associated tablespace file was not deleted. (Bug#31296)

  • Falcon could crash when the maximum record size was exceeded. (Bug#31286)

  • myisamchk --unpack could corrupt a table that when unpacked has static (fixed-length) row format. (Bug#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, Bug#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)

  • If MAKETIME() returned NULL when used in an ORDER BY that was evaluated using filesort, a server crash could result. (Bug#31160)

  • LAST_INSERT_ID() execution could be handled improperly in subqueries. (Bug#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)

  • When creating a TABLESPACE that uses the same name as an existing TABLESPACE, Falcon returned Unknown error -103. MySQL now returns an error stating that the specified tablespace already exists. (Bug#31114)

  • mysqldump failed to handle databases containing a ‘-’ character in the name. (Bug#31113)

  • Starting the server using --read-only and with the Event Scheduler enabled caused it to crash.

    Note

    This issue occurred only when the server had been built with certain nonstandard combinations of configure options.

    (Bug#31111)

  • Dropping a tablespace and specifying an engine type that does not support tablespaces reported a warning. The response has now been updated to report an error. (Bug#31110)

  • GROUP BY NULL WITH ROLLUP could cause a server crash. (Bug#31095)

    See also Bug#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)

  • 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)

  • 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)

  • Falcon would fail to compile on FreeBSD. This limitation has now been fixed. (Bug#31045)

  • Using ORDER BY with ARCHIVE tables caused a server crash. (Bug#31036)

  • The MOD() function and the % operator crashed the server for a divisor less than 1 with a very long fractional part. (Bug#31019)

  • Using falcon_serial_log_dir to set the location of the Falcon serial log would have no effect. (Bug#31005)

  • The LooseScan subquery optimization strategy could produce duplicate rows in query results. (Bug#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)

  • CHAR(str USING charset) did not check its argument and could return an ill-formed result for invalid input. (Bug#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)

  • The GeomFromText() function could cause a server crash if the first argument was NULL or the empty string. (Bug#30955)

  • When invoked with constant arguments, STR_TO_DATE() could use a cached value for the format string and return incorrect results. (Bug#30942)

  • GROUP_CONCAT() returned ',' rather than an empty string when the argument column contained only empty strings. (Bug#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)

  • Calling NAME_CONST() with non-constant arguments triggered an assertion failure. Non-constant arguments are now disallowed. (Bug#30832)

  • Running ALTER TABLE ... OPTIMIZE PARTITION on a Falcon table, a 'divide by zero' error would be reported during a server crash. (Bug#30826)

  • For a spatial column with a regular (non-SPATIAL) index, queries failed if the optimizer tried to use the index. (Bug#30825)

  • INFORMATION_SCHEMA.SCHEMATA was returning incorrect information. (Bug#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)

  • A multiple-table UPDATE involving transactional and non-transactional tables caused an assertion failure. (Bug#30763)

  • Under some circumstances, CREATE TABLE ... SELECT could crash the server or incorrectly report that the table row size was too large. (Bug#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)

  • INFORMATION_SCHEMA.VIEWS.VIEW_DEFINITION was incorrect for views that were defined to select from other INFORMATION_SCHEMA tables. (Bug#30689)

  • Issuing an ALTER SERVER statement to update the settings for a FEDERATED server would cause the mysqld to crash. (Bug#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)

  • 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)

  • MyISAM tables could not exceed 4294967295 (2^32 - 1) rows on Windows. (Bug#30638)

  • mysql-test-run.pl could not run mysqld with root privileges. (Bug#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)

  • The options available to the CHECK TABLE statement were also allowed in OPTIMIZE TABLE and ANALYZE TABLE statements, but caused corruption during their execution. These options were never supported for the these statements, and an error is now raised if you try to apply these options to these statements. (Bug#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)

  • 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)

  • A table-access check was performed improperly by libmysqld, causing a crash. (Bug#30329)

  • Some valid euc-kr characters having the second byte in the ranges [0x41..0x5A] and [0x61..0x7A] were rejected. (Bug#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)

  • Setting certain values on a table using a spatial index could cause the server to crash. (Bug#30286)

  • It was not possible for client applications to distinguish between auto-set and auto-updated TIMESTAMP column values.

    To rectify this problem, a new ON_UPDATE_NOW_FLAG flag is set by Field_timestamp constructors whenever a column should be set to NOW on UPDATE, and the get_schema_column_record() function now reports whether a timestamp column is set to NOW on UPDATE. In addition, such columns now display on update CURRENT_TIMESTAMP in the Extra column in the output from SHOW COLUMNS. (Bug#30081)

  • Some INFORMATION_SCHEMA tables are intended for internal use, but could be accessed by using SHOW statements. (Bug#30079)

  • On some 64-bit systems, inserting the largest negative value into a BIGINT column resulted in incorrect data. (Bug#30069)

  • mysqlslap did not properly handle multiple result sets from stored procedures. (Bug#29985)

  • Running the sqlbench test suite against Falcon would cause a crash. (Bug#29870)

  • When accessing the statistics in INFORMATION_SCHEMA.FALCON_DATABASE_IO, the information related only to the Falcon database, and not to user tablespaces. The output has been updated to report on all tablespaces, and the DATABASE column has been renamed to TABLESPACE to reflect the fact that these statistics are now reported by tablespace, not by database. (Bug#29823)

  • Whitespace characters other than spaces within XML tags, such as linefeeds or tabs, caused LOAD XML INFILE to skip rows. (Bug#29752)

  • configure did not find nss on some Linux platforms. (Bug#29658)

  • Compilation failed on systems where a native log2() implementation was unavailable. (Bug#29640)

  • Use of the latin2_czech_cs collation caused a server crash. (Bug#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)

  • 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.

    Presence of a BOM does not cause mysql to change its default character set. To do that, invoke mysql with an option such as --default-character-set=utf8. (Bug#29323)

  • Inserting 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 behavior of Falcon is similar to that in InnoDB. (Bug#29151)

  • For transactional tables, an error during a multiple-table DELETE statement did not roll back the statement. (Bug#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. Also, attempting to set them with SET produced an incorrect Unknown system variable message. Now these variables are treated as synonyms for general_log and slow_query_log, which means that they can be accessed in expressions and their values can be changed with SET. (Bug#29131)

  • When loading large data sets using LOAD DATA INFILE into a Falcon table, the server could crash. (Bug#29081)

  • SHOW VARIABLES did not display the relay_log, relay_log_index, or relay_log_info_file system variables. (Bug#28893)

  • Index hints specified in view definitions were ignored when using the view to select from the base table. (Bug#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)

  • 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)

  • The result from CHAR() was incorrectly assumed in some contexts to return a single-byte result. (Bug#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)

  • Under heavy load when updating Falcon tables, a race condition could occur that would ultimately result in a crash. (Bug#28519)

  • The result of a comparison between VARBINARY and BINARY columns differed depending on whether the VARBINARY column was indexed. (Bug#28076)

  • The metadata in some MYSQL_FIELD members could be incorrect when a temporary table was used to evaluate a query. (Bug#27990)

  • It was possible to create a view having a column whose name consisted of an empty string or space characters only. (Bug#27695)

    See also Bug#31202

  • ALTER TABLE tbl_name ROW_FORMAT=format_type did not cause the table to be rebuilt. (Bug#27610)

  • Searching a Falcon table that uses DATETIME columns with an index could return incorrect results. (Bug#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)

  • Mixing differently cased tables between MyISAM and Falcon tables would cause a crash. (Bug#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)

  • On Windows, writes to the debug log were using freopen() instead of fflush(), resulting in slower performance. (Bug#27099)

  • Connections from one mysqld server to another failed on Mac OS X, affecting replication and FEDERATED tables. (Bug#26664)

    See also Bug#29083

  • LOAD DATA INFILE ran very slowly when reading large files into partitioned tables. (Bug#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)

  • For mysql --show-warnings, warnings were in some cases not displayed. (Bug#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)

  • 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)

  • 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)

  • Creating a new table or dropping a database on a newly created Falcon database or tablespace raised an error. (Bug#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)

  • 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)

  • Selecting information from a Falcon table using a DOUBLE column with an index would produce incorrect results. (Bug#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)

  • 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, Bug#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 considerable. This was because the DISABLE KEYS operation would only mark the existing index, without deleting the index blocks. The ENABLE KEYS operation would re-create the index, adding new blocks, while the previous index blocks would remain. Existing indexes are now dropped and recreated when the ENABLE KEYS statement is executed. (Bug#4692)