Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting
Applications: MySQL > doc > refman > 6.0 > ennews-6-0-4.html (Request Expert MySQL Support)
Skip navigation links

Additional languages

    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.

        Do you need help?X

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

      Do you need more help?X

      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.

      Can we help you?X

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

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

      Can't find what you're looking for?X

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

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

      Don't know where to look next?X

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

      Confused? Frustrated?X

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

      Call Pantek today for Open Source Technical Support at 1-877-546-8934 - 24/7/365X

    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)

      Do you need help?X

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

        Do you need more help?X

        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.

        Can we help you?X

        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)".

        Can't find what you're looking for?X

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

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

      Don't know where to look next?X

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

      Confused? Frustrated?X

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

      Call Pantek today for Open Source Technical Support at 1-877-546-8934 - 24/7/365X

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

      Do you need help?X

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

      Do you need more help?X

    • 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

      Can we help you?X

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

      Can't find what you're looking for?X

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

      Don't know where to look next?X

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

      Confused? Frustrated?X

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

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

      Call Pantek today for Open Source Technical Support at 1-877-546-8934 - 24/7/365X

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

      Do you need help?X

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

      Do you need more help?X

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

      Can we help you?X

    • 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

      Can't find what you're looking for?X

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

      Don't know where to look next?X

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