Documentation Home
MySQL 5.1 Release Notes
Related Documentation Download these Release Notes
PDF (US Ltr) - 2.1Mb
PDF (A4) - 2.1Mb
EPUB - 0.5Mb

MySQL 5.1 Release Notes  /  Changes in MySQL 5.1.21 (2007-08-16)

Changes in MySQL 5.1.21 (2007-08-16)

This is a new Beta development release, fixing recently discovered bugs.


This Beta release, as any other pre-production release, should not be installed on production level systems or systems with critical data. It is good practice to back up your data before installing any new version of software. Although MySQL has worked very hard to ensure a high level of quality, protect your data by making a backup as you would for any software beta release. Please refer to our bug database at for more details about the individual bugs fixed in this version.


Subsequent to release, it was discovered that on some platforms, mysql_install_db could fail to find its message file, resulting in error messages of the following form:

shell> mysql_install_db
Installing MySQL system tables...
070830  9:33:24 [ERROR] Can't find messagefile 'path/share/english/errmsg.sys'
070830  9:33:24 [ERROR] Aborting

To deal with this problem, specify a --language option to specify the proper path name to the language file directory. For example:

shell> mysql_install_db --language=/path/to/share/english/

This problem is corrected in MySQL 5.1.22.

This section documents all changes and bug fixes that have been applied since the last official MySQL release. If you would like to receive more fine-grained and personalized update alerts about fixes that are relevant to the version and features you use, please consider subscribing to MySQL Enterprise (a commercial MySQL offering). For more details, please see (

Functionality Added or Changed

  • Incompatible Change: In MySQL 5.1.6, when log tables were implemented, the default log destination for the general query and slow query log was TABLE. This default has been changed to FILE, which is compatible with MySQL 5.0, but incompatible with earlier releases of MySQL 5.1 from 5.1.6 to 5.1.20. If you are upgrading from MySQL 5.0 to 5.1.21 or higher, no logging option changes should be necessary. However, if you are upgrading from 5.1.6 through 5.1.20 to 5.1.21 or higher and were using TABLE logging, use the --log-output=TABLE option explicitly to preserve your server's table-logging behavior.

    A further fix for this issue was made in MySQL 5.1.23. (Bug #29993)

  • Incompatible Change: On Windows only, the mysqld-nt has been removed from this release and all future releases. The mysqld server now includes named-pipe support as standard, and you do not have to use the mysqld-nt version to enable named-pipe support.

  • Incompatible Change: The innodb_log_arch_dir system variable (which has been deprecated since MySQL 5.0.24) has been removed and should no longer be used.

  • Important Change: The default mysqld_safe logging behavior now is --skip-syslog rather than --syslog, which is compatible with the default behavior of writing an error log file for releases prior to 5.1.20.

  • Replication: The SQL thread on a slave now is always permitted to enter InnoDB even if this would exceed the limit imposed by the innodb_thread_concurrency system variable. In cases of high load on the slave server (when innodb_thread_concurrency is reached), this change helps the slave stay more up to date with the master; in the previous behavior, the SQL thread was competing for resources with all client threads active on the slave server. (Bug #25078)

  • Replication: Replication between master and slaves now supports different column numbers within a table on both master and slave. The rules for replication where the table definitions are different has also changed. This supersedes the functionality for replication from the master table to a slave table with more columns that was added in MySQL 5.1.12. For more information, see Replication with Differing Table Definitions on Master and Slave.

  • Several programs now accept --debug-check and --debug-info options: mysql, mysqladmin, mysqlbinlog, mysqlcheck, mysqldump, mysqlimport, mysqlshow, mysqlslap, mysqltest, mysql_upgrade. (Note: mysql, mysqladmin, mysqlcheck, mysqldump, mysqlimport, mysqlshow, and mysqltest already accepted --debug-info.) --debug-check prints debugging information at program exit. --debug-info is similar but also prints memory and CPU usage statistics. This patch also corrects a problem for mysql that --debug-info did not display statistics at exit time. (Bug #30127)

  • The --syslog option that was introduced in 5.1.20 for mysqld_safe (to send error output to syslog) did not work correctly: Error output was buffered and not logged immediately. This has been corrected. In addition, some feature changes were made:

    • Important

      The default mysqld_safe logging behavior now is --skip-syslog rather than --syslog, which is compatible with the default behavior of writing an error log file for releases prior to 5.1.20.

    • A new option, --syslog-tag=tag , modifies the default tags written by mysqld_safe and mysqld to syslog to be mysqld_safe-tag and mysqld-tag rather than the default tags of mysqld_safe and mysqld.

    (Bug #29992)

  • Transaction support in the FEDERATED storage engine has been disabled due to issues with multiple active transactions and sessions on the same FEDERATED table. (Bug #29875)

  • Previously, prepared statements processed using PREPARE and EXECUTE were not subject to caching in the query cache if they contained any ? parameter markers. This limitation has been lifted. (Bug #29318)

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

  • Log table locking was redesigned, eliminating several lock-related problems:

    • Truncating mysql.slow_log in a stored procedure after use of a cursor caused the thread to lock.

    • Flushing a log table resulted in unnecessary warnings.

    • The server would hang when performing concurrent ALTER TABLE or TRUNCATE TABLE statements against the log tables.

    • Changing the value of the general_log system variable while a global read lock was in place resulted in deadlock.

    The changes provide better-defined interface characteristics. See Selecting General Query and Slow Query Log Output Destinations. (Bug #17876, Bug #23044, Bug #25422, Bug #29129)

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

  • A new option, --syslog-tag=tag , modifies the default tags written by mysqld_safe and mysqld to syslog to be mysqld_safe-tag and mysqld-tag rather than the default tags of mysqld_safe and mysqld.

  • Added the --commit, --detach, --post-system, and --pre-system options for mysqlslap.

Bugs Fixed

  • Incompatible Change: Failure to consider collation when comparing space characters could result in incorrect index entry order, leading to incorrect comparisons, inability to find some index values, misordered index entries, misordered ORDER BY results, or tables that CHECK TABLE reports as having corrupt indexes.

    As a result of this bug fix, indexes must be rebuilt for columns that use any of these character sets: eucjpms, euc_kr, gb2312, latin7, macce, ujis. See Checking Whether Tables or Indexes Must Be Rebuilt. (Bug #29461)

  • Incompatible Change: Several issues were identified for stored programs (stored procedures and functions, triggers, and events) and views containing non-ASCII symbols. These issues involved conversion errors due to incomplete character set information when translating these objects to and from stored format, such as:

    • Parsing the original object definition so that it can be stored.

    • Compiling the stored definition into executable form when the object is invoked.

    • Retrieval of object definitions from INFORMATION_SCHEMA tables.

    • Displaying the object definition in SHOW statements. This issue also affected mysqldump, which uses SHOW.

    The fix for the problems is to store character set information from the object creation context so that this information is available when the object needs to be used later. The context includes the client character set, the connection character set and collation, and the collation of the database with which the object is associated.

    As a result of the patch, several tables have new columns:

    • In the mysql database, the proc and event tables now have these columns: character_set_client, collation_connection, db_collation, body_utf8.


    These columns store the session values of the character_set_client and collation_connection system variables, and the collation of the database with which the object is associated. The values are those in effect at object creation time. (The saved database collation is not the value of the collation_database system variable, which applies to the default database; the database that contains the object is not necessarily the default database.)

    Several SHOW statements now display additional columns corresponding to the new table columns. These statements are: SHOW CREATE EVENT, SHOW CREATE FUNCTION, SHOW CREATE PROCEDURE, SHOW CREATE VIEW, SHOW EVENTS, SHOW FUNCTION STATUS, SHOW PROCEDURE STATUS, SHOW TRIGGERS.

    A new statement, SHOW CREATE TRIGGER is introduced and is used by mysqldump for producing CREATE TRIGGER statements.

    mysqldump output now can include ALTER DATABASE statements that change the database collation. These may be used when dumping stored programs to preserve their character encodings. To reload a dump file containing such statements, the ALTER privilege for the affected database is required.

    Subsequent to the patch just described, it was discovered that the patch broke mysql_upgrade; this has been corrected.


    The fixes for the problems just describe affect all existing stored programs and views. (For example, you will see warnings about no creation context.) To avoid warnings from the server about the use of old definitions from any release prior to 5.1.21, you should dump stored programs and views with mysqldump after upgrading to 5.1.21, and then reload them to recreate them with new definitions. Invoke mysqldump with a --default-character-set option that names the non-ASCII character set that was used for the definitions when the objects were originally created, and the --routines, --events, and --triggers options to dump stored program definitions. For more information about upgrading stored programs, see Changes Affecting Upgrades to 5.1.

    (Bug #25221, Bug #21249, Bug #30027, Bug #16291, Bug #11986, Bug #25212, Bug #19443, Bug #30029)

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

  • MySQL Cluster: DELETE FROM table WHERE primary_key IN (value_list), where the value_list contained more than one value, called from an AFTER DELETE trigger on an NDB table, caused mysqld to crash. (Bug #30337)

  • MySQL Cluster: When restarting a data node, queries could hang during that node's start phase 5, and continue only after the node had entered phase 6. (Bug #29364)

  • MySQL Cluster: Replica redo logs were inconsistently handled during a system restart. (Bug #29354)

  • MySQL Cluster: When a node failed to respond to a COPY_GCI signal as part of a global checkpoint, the master node was killed instead of the node that actually failed. (Bug #29331)

  • MySQL Cluster: An invalid comparison made during REDO validation that could lead to an Error while reading REDO log condition. (Bug #29118)

  • MySQL Cluster: The wrong data pages were sometimes invalidated following a global checkpoint. (Bug #29067)

  • MySQL Cluster: If at least 2 files were involved in REDO invalidation, then file 0 of page 0 was not updated and so pointed to an invalid part of the redo log. (Bug #29057)

  • MySQL Cluster: If a storage engine has its own logging capability, then any statement using both this engine and some other engine not having its own logging could not be correctly logged, due to the fact that entries from one engine could be logged before entries from the other engine were. This did not generate any error messages when it occurred.

    Now, if multiple storage engines are used in a statement and at least one of them has its own logging capability, then an error message is generated and the statement is not executed.


    Currently, the only storage engine to have its own logging capability is NDBCLUSTER.

    (Bug #28722)

  • MySQL Cluster: Warnings and errors generated by ndb_config --config-file=file were sent to stdout, rather than to stderr. (Bug #25941)

  • MySQL Cluster: When a cluster backup was terminated using the ABORT BACKUP command in the management client, a misleading error message Backup aborted by application: Permanent error: Internal error was returned. The error message returned in such cases now reads Backup aborted by user request. (Bug #21052)

  • MySQL Cluster: Large file support did not work in AIX server binaries. (Bug #10776)

  • Replication: The thread ID was not reset properly after execution of mysql_change_user(), which could cause replication failure when replicating temporary tables. (Bug #29734)

  • Replication: Storage engine error conditions in row-based replication were not correctly reported to the user. (Bug #29570)

  • Replication: INSERT DELAYED statements on a master server are replicated as non-DELAYED inserts on slaves (which is normal, to preserve serialization), but the inserts on the slave did not use concurrent inserts. Now INSERT DELAYED on a slave is converted to a concurrent insert when possible, and to a normal insert otherwise. (Bug #29152)

  • Replication: An error that happened inside INSERT, UPDATE, or DELETE statements performed from within a stored function or trigger could cause inconsistency between master and slave servers. (Bug #27417)

  • Replication: Slave servers could incorrectly interpret an out-of-memory error from the master and reconnect using the wrong binary log position. (Bug #24192)

  • Replication: Using the READ COMMITTED transaction isolation level caused mixed and statement-based replication to fail. (Bug #23051)

  • Disk Data: Performing Disk Data schema operations during a node restart could cause forced shutdowns of other data nodes. (Bug #29501)

  • Disk Data: When dropping a page, the stack's bottom entry could sometime be left cold rather than hot, violating the rules for stack pruning. (Bug #29176)

  • Disk Data: Disk data meta-information that existed in ndbd might not be visible to mysqld. (Bug #28720)

  • Disk Data: The number of free extents was incorrectly reported for some tablespaces. (Bug #28642)

  • Cluster Replication: When executing a statement where binlog_format = statement, the result of the statement was logged both as a statement and as rows. (Bug #29222)

  • Cluster Replication: mysqld would segfault on startup when the NDB storage engine was enabled and the default character set was a strictly multibyte character set such as UCS2.

    This issue does not apply to character sets that can contain single-byte characters in addition to multibyte characters such as UTF-8.

    Additional issues remain with regard to the use of multibyte character sets in MySQL Cluster Replication; see Known Issues in MySQL Cluster Replication, for more information. (Bug #27404)

  • Prepared statements containing CONNECTION_ID() could be written improperly to the binary log. (Bug #30200)

  • Use of local variables with non-ASCII names in stored procedures crashed the server. (Bug #30120)

  • On Windows, client libraries lacked symbols required for linking. (Bug #30118)

  • --myisam-recover='' (empty option value) did not disable MyISAM recovery. (Bug #30088)

  • For the SHOW TABLE TYPES statement, the server sent incorrect output to clients, possibly causing them to crash. (Bug #30036)

  • The IS_UPDATABLE column in the INFORMATION_SCHEMA.VIEWS table was not always set correctly. (Bug #30020)

  • SHOW statements were being written to the slow query log that should not have been. (Bug #30000)

  • REPAIR TABLE ... USE_FRM could corrupt tables. (Bug #29980)

  • For MyISAM tables on Windows, INSERT, DELETE, or UPDATE followed by ALTER TABLE within LOCK TABLES could cause table corruption. (Bug #29957)

  • LOCK TABLES did not pre-lock tables used in triggers of the locked tables. Unexpected locking behavior and statement failures similar to failed: 1100: Table 'xx' was not locked with LOCK TABLES could result. (Bug #29929)

  • INSERT ... VALUES(CONNECTION_ID(), ...) statements were written to the binary log in such a way that they could not be properly restored. (Bug #29928)

  • Adding DISTINCT could cause incorrect rows to appear in a query result. (Bug #29911)

  • On Windows, the CMake build process did not produce the embedded server library or related binaries. (Bug #29903)

  • Using the DATE() function in a WHERE clause did not return any records after encountering NULL. However, using TRIM() or CAST() produced the correct results. (Bug #29898)

  • SESSION_USER() returned garbage data (rather than the correct value of the empty string) when executed by a slave SQL thread. (Bug #29878)

  • Very long prepared statements in stored procedures could cause a server crash. (Bug #29856)

  • If query execution involved a temporary table, GROUP_CONCAT() could return a result with an incorrect character set. (Bug #29850)

  • If one thread was performing concurrent inserts, other threads reading from the same table using equality key searches could see the index values for new rows before the data values had been written, leading to reports of table corruption. (Bug #29838)

  • Repeatedly accessing a view in a stored procedure (for example, in a loop) caused a small amount of memory to be allocated per access. Although this memory is deallocated on disconnect, it could be a problem for a long running stored procedures that make repeated access of views. (Bug #29834)

  • mysqldump produced output that incorrectly discarded the NO_AUTO_VALUE_ON_ZERO value of the sql_mode variable after dumping triggers. (Bug #29788)

  • An assertion failure occurred within yaSSL for very long keys. (Bug #29784)

    References: See also Bug #53463.

  • For MEMORY tables, the index_merge union access method could return incorrect results. (Bug #29740)

  • Comparison of TIME values using the BETWEEN operator led to string comparison, producing incorrect results in some cases. Now the values are compared as integers. (Bug #29739)

  • For a table with a DATE column date_col such that selecting rows with WHERE date_col = 'date_val 00:00:00' yielded a nonempty result, adding GROUP BY date_col caused the result to be empty. (Bug #29729)

  • In some cases, INSERT INTO ... SELECT ... GROUP BY could insert rows even if the SELECT by itself produced an empty result. (Bug #29717)

  • Single-row inserts could report a row count greater than one. (Bug #29692)

  • For the embedded server, the mysql_stmt_store_result() C API function caused a memory leak for empty result sets. (Bug #29687)

  • EXPLAIN produced Impossible where for statements of the form SELECT ... FROM t WHERE c=0, where c was an ENUM column defined as a primary key. (Bug #29661)

  • On Windows, ALTER TABLE hung if records were locked in share mode by a long-running transaction. (Bug #29644)

  • mysqld_safe produced error messages and did not create the error log file under some circumstances. (Bug #29634)

  • On 64-bit platforms, the filesort code (for queries with GROUP BY or ORDER BY) could crash due to an incorrect pointer size. (Bug #29610)

  • A left join between two views could produce incorrect results. (Bug #29604)

  • Certain statements with unions, subqueries, and joins could result in huge memory consumption. (Bug #29582)

  • Clients using SSL could hang the server. (Bug #29579)

  • A slave running with --log-slave-updates failed to write INSERT DELAY IGNORE statements to its binary log, resulting in different binary log contents on the master and slave. (Bug #29571)

  • An incorrect result was returned when comparing string values that were converted to TIME values with CAST(). (Bug #29555)

  • gcov coverage-testing information was not written if the server crashed. (Bug #29543)

  • In the ascii character set, conversion of DEL (0x7F) to Unicode incorrectly resulted in QUESTION MARK (0x3F) rather than DEL. (Bug #29499)

  • A field packet with NULL fields caused a libmysqlclient crash. (Bug #29494)

  • On Windows, the mysql client died if the user entered a statement and Return after entering Control+C. (Bug #29469)

  • The full-text parser could enter an infinite loop if it encountered an illegal multibyte sequence or a sequence that has no mapping to Unicode. (Bug #29464)

  • Searching a FULLTEXT index for a word with the boolean mode truncation operator could cause an infinite loop. (Bug #29445)

  • Corrupt data resulted from use of SELECT ... INTO OUTFILE 'file_name' FIELDS ENCLOSED BY 'c', where c is a digit or minus sign, followed by LOAD DATA INFILE 'file_name' FIELDS ENCLOSED BY 'c'. (Bug #29442)

  • Killing an INSERT DELAYED thread caused a server crash. (Bug #29431)

  • Use of SHOW BINLOG EVENTS for a nonexistent log file followed by PURGE BINARY LOGS caused a server crash. (Bug #29420)

  • Assertion failure could occur for grouping queries that employed DECIMAL user variables with assignments to them. (Bug #29417)

  • For CAST(expr AS DECIMAL(M,D)), the limits of 65 and 30 on the precision (M) and scale (D) were not enforced. (Bug #29415)

  • Deleting from a CSV table could corrupt it. (Bug #29411)

  • Results for a select query that aliases the column names against a view could duplicate one column while omitting another. This bug could occur for a query over a multiple-table view that includes an ORDER BY clause in its definition. (Bug #29392)

  • mysqldump created a stray file when a given a too-long file name argument. (Bug #29361)

  • The special zero ENUM value was coerced to the normal empty string ENUM value during a column-to-column copy. This affected CREATE ... SELECT statements and SELECT statements with aggregate functions on ENUM columns in the GROUP BY clause. (Bug #29360)

  • Inserting a negative number into a CSV table could corrupt it. (Bug #29353)

  • Optimization of queries with DETERMINISTIC stored functions in the WHERE clause was ineffective: A sequential scan was always used. (Bug #29338)

  • MyISAM corruption could occur with the cp932_japanese_ci collation for the cp932 character set due to incorrect comparison for trailing space. (Bug #29333)

  • For updates to InnoDB tables, a TIMESTAMP column with the ON UPDATE CURRENT_TIMESTAMP attribute could be updated even when no values actually changed. (Bug #29310)

  • FULLTEXT indexes could be corrupted by certain gbk characters. (Bug #29299)

  • SELECT ... INTO OUTFILE followed by LOAD DATA could result in garbled characters when the FIELDS ENCLOSED BY clause named a delimiter of '0', 'b', 'n', 'r', 't', 'N', or 'Z' due to an interaction of character encoding and doubling for data values containing the enclosed-by character. (Bug #29294)

  • Sort order of the collation wasn't used when comparing trailing spaces. This could lead to incorrect comparison results, incorrectly created indexes, or incorrect result set order for queries that include an ORDER BY clause. (Bug #29261)

  • CHECK TABLE could erroneously report table corruption for a CSV table if multiple threads were modifying the table at the same time. (Bug #29253)

  • Many threads accessing a CSV table simultaneously could cause an assertion failure. (Bug #29252)

  • If an ENUM column contained '' as one of its members (represented with numeric value greater than 0), and the column contained error values (represented as 0 and displayed as ''), using ALTER TABLE to modify the column definition caused the 0 values to be given the numeric value of the nonzero '' member. (Bug #29251)

  • Calling mysql_options() after mysql_real_connect() could cause clients to crash. (Bug #29247)

  • CHECK TABLE for ARCHIVE tables could falsely report table corruption or cause a server crash. (Bug #29207)

  • Mixing binary and utf8 columns in a union caused field lengths to be calculated incorrectly, resulting in truncation. (Bug #29205)

  • AsText() could fail with a buffer overrun. (Bug #29166)

  • Under some circumstances, a SELECT ... FROM mysql.event could cause the server to crash. (Bug #29156)

  • InnoDB refused to start on some versions of FreeBSD with LinuxThreads. This is fixed by enabling file locking on FreeBSD. (Bug #29155)

  • LOCK TABLES was not atomic when more than one InnoDB tables were locked. (Bug #29154)

  • mysqld failed to exit during shutdown. (Bug #29133)

  • A network structure was initialized incorrectly, leading to embedded server crashes. (Bug #29117)

  • An assertion failure occurred if a query contained a conjunctive predicate of the form view_column = constant in the WHERE clause and the GROUP BY clause contained a reference to a different view column. The fix also enables application of an optimization that was being skipped if a query contained a conjunctive predicate of the form view_column = constant in the WHERE clause and the GROUP BY clause contained a reference to the same view column. (Bug #29104)

  • A maximum of 4TB InnoDB free space was reported by SHOW TABLE STATUS, which is incorrect on systems with more than 4TB space. (Bug #29097)

  • If an INSERT INTO ... SELECT statement inserted into the same table that the SELECT retrieved from, and the SELECT included ORDER BY and LIMIT clauses, different data was inserted than the data produced by the SELECT executed by itself. (Bug #29095)

  • Queries that performed a lookup into a BINARY index containing key values ending with spaces caused an assertion failure for debug builds and incorrect results for nondebug builds. (Bug #29087)

  • The semantics of BIGINT depended on platform-specific characteristics. (Bug #29079)

  • A byte-order issue in writing a spatial index to disk caused bad index files on some systems. (Bug #29070)

  • Creation of a legal stored procedure could fail if no default database had been selected. (Bug #29050)

  • REPLACE, INSERT IGNORE, and UPDATE IGNORE did not work for FEDERATED tables. (Bug #29019)

  • Inserting into InnoDB tables and executing RESET MASTER in multiple threads cause assertion failure in debug server binaries. (Bug #28983)

  • Updates to a CSV table could cause a server crash or update the table with incorrect values. (Bug #28971)

  • For a ucs2 column, GROUP_CONCAT() did not convert separators to the result character set before inserting them, producing a result containing a mixture of two different character sets. (Bug #28925)

  • Dropping the definer of an active event caused the server to crash. (Bug #28924)

  • For a join with GROUP BY or ORDER BY and a view reference in the FROM list, the query metadata erroneously showed empty table aliases and database names for the view columns. (Bug #28898)

  • Creating an event using ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL ... could in some cases cause mysqld to crash. (Bug #28881)

  • Coercion of ASCII values to character sets that are a superset of ASCII sometimes was not done, resulting in illegal mix of collations errors. These cases now are resolved using repertoire, a new string expression attribute (see String Repertoire). (Bug #28875)

  • Executing ALTER EVENT on an event whose definer's event creation privileges had been revoked cause the server to crash. (Bug #28873)

  • ALTER VIEW is not supported as a prepared statement but was not being rejected. ALTER VIEW is now prohibited as a prepared statement or when called within stored routines. (Bug #28846)

  • In strict SQL mode, errors silently stopped the SQL thread even for errors named using the --slave-skip-errors option. (Bug #28839)

  • Fast ALTER TABLE (that works without rebuilding the table) acquired duplicate locks in the storage engine. In MyISAM, if ALTER TABLE was issued under LOCK TABLE, it caused all data inserted after LOCK TABLE to disappear. (Bug #28838)

  • Runtime changes to the log_queries_not_using_indexes system variable were ignored. (Bug #28808)

  • Selecting a column not present in the selected-from table caused an extra error to be produced by SHOW ERRORS. (Bug #28677)

  • Creating an event to be executed at a time close to the end of the permitted range (2038-01-19 03:14:07 UTC) would cause the server to crash. (Bug #28641)

  • For a statement of the form CREATE t1 SELECT integer_constant, the server created the column using the DECIMAL data type for large negative values that are within the range of BIGINT. (Bug #28625)

  • Starting the server with an innodb_force_recovery value of 4 did not work. (Bug #28604)

  • For InnoDB tables, MySQL unnecessarily sorted records in certain cases when the records were retrieved by InnoDB in the proper order already. (Bug #28591)

  • mysql_install_db could fail to find script files that it needs. (Bug #28585)

  • If a stored procedure was created and invoked prior to selecting a default database with USE, a No database selected error occurred. (Bug #28551)

  • On Mac OS X, shared-library installation path names were incorrect. (Bug #28544)

  • Using the --skip-add-drop-table option with mysqldump generated incorrect SQL if the database included any views. The recreation of views requires the creation and removal of temporary tables. This option suppressed the removal of those temporary tables. The same applied to --compact since this option also invokes --skip-add-drop-table. (Bug #28524)

  • mysqlbinlog --hexdump generated incorrect output due to omission of the # comment character for some comment lines. (Bug #28293)

  • InnoDB could crash if the server was shut down while innodb_table_monitor was running. (Bug #28254)

  • A race condition in the interaction between MyISAM and the query cache code caused the query cache not to invalidate itself for concurrently inserted data. (Bug #28249)

  • A duplicate-key error message could display an incorrect key value when not all columns of the key were used to select rows for update. (Bug #28158)

  • Indexing column prefixes in InnoDB tables could cause table corruption. (Bug #28138)

  • Index creation could fail due to truncation of key values to the maximum key length rather than to a multiple of the maximum character length. (Bug #28125)

  • Instance Manager had a race condition when it received a shutdown request while a guarded mysqld instance was starting such that it could fail to stop the mysqld instance. (Bug #28030)

  • SELECT ... FOR UPDATE with partitioned tables could cause a server crash. (Bug #28026)

  • On Windows, Instance Manager would crash if an instance object failed to initialize during startup. This could happen if an incorrect mysqld path was supplied in the configuration file. (Bug #28012)

  • The LOCATE() function returned NULL if any of its arguments evaluated to NULL. Likewise, the predicate, LOCATE(str,NULL) IS NULL, erroneously evaluated to FALSE. (Bug #27932)

  • Dropping a user-defined function could cause a server crash if the function was still in use by another thread. (Bug #27564)

  • For some event-creation problems, the server displayed messages that implied the problems were errors when they were only warnings. (Bug #27406)

  • Unsafe aliasing in the source caused a client library crash when compiled with gcc 4 at high optimization levels. (Bug #27383)

  • Index-based range reads could fail for comparisons that involved contraction characters (such as ch in Czech or ll in Spanish). (Bug #27345)

  • Aggregations in subqueries that refer to outer query columns were not always correctly referenced to the proper outer query. (Bug #27333)

  • Error returns from the time() system call were ignored. (Bug #27198)

  • Phantom reads could occur under InnoDB SERIALIZABLE isolation level. (Bug #27197)

  • The SUBSTRING() function returned the entire string instead of an empty string when it was called from a stored procedure and when the length parameter was specified by a variable with the value 0. (Bug #27130)

  • Some functions when used in partitioning expressions could cause mysqld to crash. (Bug #27084)

  • The server acquired a global mutex for temporary tables, although such tables are thread-specific. This affected performance by blocking other threads. (Bug #27062)

  • FEDERATED tables had an artificially low maximum of key length. (Bug #26909)

  • Updates to rows in a partitioned table could update the wrong column. (Bug #26827)

  • Index creation could corrupt the table definition in the .frm file: 1) A table with the maximum number of key segments and maximum length key name would have a corrupted .frm file, due to incorrect calculation of the total key length. 2) MyISAM would reject a table with the maximum number of keys and the maximum number of key segments in all keys. (It would permit one less than this total maximum.) Now MyISAM accepts a table defined with the maximum. (Bug #26642)

  • The Windows implementation of pthread_join() was incorrect and could cause crashes. (Bug #26564)

  • After the first read of a TEMPORARY table, CHECK TABLE could report the table as being corrupt. (Bug #26325)

  • If an operation had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (such as two distinct MyISAM tables), the triggers were unable to execute concurrently. In addition, INSERT and UPDATE statements for the InnoDB table were unable to run concurrently. (Bug #26141)

  • A number of unsupported constructs—including prohibited constructs, the UCASE() function, and nested function calls—were permitted in partitioning expressions. (Bug #26082, Bug #18198, Bug #29308)

  • ALTER DATABASE did not require at least one option. (Bug #25859)

  • The index merge union access algorithm could produce incorrect results with InnoDB tables. The problem could also occur for queries that used DISTINCT. (Bug #25798)

  • When using a FEDERATED table, the value of LAST_INSERT_ID() would not correctly update the C API interface, which would affect the autogenerated ID returned both through the C API and the MySQL protocol, affecting Connectors that used the protocol or C API. (Bug #25714)

  • The server was blocked from opening other tables while the FEDERATED engine was attempting to open a remote table. Now the server does not check the correctness of a FEDERATED table at CREATE TABLE time, but waits until the table actually is accessed. (Bug #25679)

  • Under ActiveState Perl, could kill itself when attempting to kill other processes. (Bug #25657)

  • Several InnoDB assertion failures were corrected. (Bug #25645)

  • A query with DISTINCT in the select list to which the loose-scan optimization for grouping queries was applied returned an incorrect result set when the query was used with the SQL_BIG_RESULT option. (Bug #25602)

  • For a multiple-row insert into a FEDERATED table that refers to a remote transactional table, if the insert failed for a row due to constraint failure, the remote table would contain a partial commit (the rows preceding the failed one) instead of rolling back the statement completely. This occurred because the rows were treated as individual inserts.

    Now FEDERATED performs bulk-insert handling such that multiple rows are sent to the remote table in a batch. This provides a performance improvement and enables the remote table to perform statement rollback properly should an error occur. This capability has the following limitations:

    • The size of the insert cannot exceed the maximum packet size between servers. If the insert exceeds this size, it is broken into multiple packets and the rollback problem can occur.

    • Bulk-insert handling does not occur for INSERT ... ON DUPLICATE KEY UPDATE.

    (Bug #25513)

  • The FEDERATED storage engine failed silently for INSERT ... ON DUPLICATE KEY UPDATE if a duplicate key violation occurred. FEDERATED does not support ON DUPLICATE KEY UPDATE, so now it correctly returns an ER_DUP_KEY error if a duplicate key violation occurs. (Bug #25511)

  • In a stored function or trigger, when InnoDB detected deadlock, it attempted rollback and displayed an incorrect error message (Explicit or implicit commit is not permitted in stored function or trigger). Now InnoDB returns an error under these conditions and does not attempt rollback. Rollback is handled outside of InnoDB above the function/trigger level. (Bug #24989)

  • Dropping a temporary InnoDB table that had been locked with LOCK TABLES caused a server crash. (Bug #24918)

  • On Windows, executables did not include Vista manifests. (Bug #24732)

    References: See also Bug #22563.

  • If MySQL/InnoDB crashed very quickly after starting up, it would not force a checkpoint. In this case, InnoDB would skip crash recovery at next startup, and the database would become corrupt. Now, if the redo log scan at InnoDB startup goes past the last checkpoint, crash recovery is forced. (Bug #23710)

  • SHOW INNODB STATUS caused an assertion failure under high load. (Bug #22819)

  • SHOW BINLOG EVENTS displayed incorrect values of End_log_pos for events associated with transactional storage engines. (Bug #22540)

  • When determining which transaction to kill after deadlock has been detected, InnoDB now adds the number of locks to a transaction's weight, and avoids killing transactions that mave modified nontransactional tables. This should reduce the likelihood of killing long-running transactions containing SELECT ... FOR UPDATE or INSERT/REPLACE INTO ... SELECT statements, and of causing partial updates if the target is a MyISAM table. (Bug #21293)

  • InnoDB displayed an incorrect error message when a CREATE TABLE statement exceeded the InnoDB maximum permissible row size. (Bug #21101)

  • Under heavy load with a large query cache, invalidating part of the cache could cause the server to freeze (that is, to be unable to service other operations until the invalidation was complete). (Bug #21074)

    References: See also Bug #39253.

  • On Windows, the server used 10MB of memory for each connection thread, resulting in memory exhaustion. Now each thread uses 1MB. (Bug #20815)

  • InnoDB produced an unnecessary (and harmless) warning: InnoDB: Error: trying to declare trx to enter InnoDB, but InnoDB: it already is declared. (Bug #20090)

  • If a slave timed out while registering with the master to which it was connecting, auto-reconnect failed thereafter. (Bug #19328)

  • If InnoDB reached its limit on the number of concurrent transactions (1023), it wrote a descriptive message to the error log but returned a misleading error message to the client, or an assertion failure occurred. (Bug #18828)

    References: See also Bug #46672.

  • Under ActiveState Perl, would not run. (Bug #18415)

  • The server crashed when the size of an ARCHIVE table grew larger than 2GB. (Bug #15787)

  • SQL_BIG_RESULT had no effect for CREATE TABLE ... SELECT SQL_BIG_RESULT ... statements. (Bug #15130)

  • On 64-bit Windows systems, the Config Wizard failed to complete the setup because 64-bit Windows does not resolve dynamic linking of the 64-bit libmysql.dll to a 32-bit application like the Config Wizard. (Bug #14649)

  • mysql_setpermission tried to grant global-only privileges at the database level. (Bug #14618)

  • For the general query log, logging of prepared statements executed using the C API differed from logging of prepared statements performed with PREPARE and EXECUTE. Logging for the latter was missing the Prepare and Execute lines. (Bug #13326)

  • The TABLE_COMMENT column of INFORMATION_SCHEMA.TABLES and the Comment column in the output of SHOW TABLE STATUS displayed extraneous information for InnoDB and NDBCLUSTER tables. (Bug #11379)

    References: See also Bug #32440.

  • The server returned data from SHOW CREATE TABLE statement or a SELECT statement on an INFORMATION_SCHEMA table using the binary character set. (Bug #10491)

  • Backup software can cause ERROR_SHARING_VIOLATION or ERROR_LOCK_VIOLATION conditions during file operations. InnoDB now retries forever until the condition goes away. (Bug #9709)

Download these Release Notes
PDF (US Ltr) - 2.1Mb
PDF (A4) - 2.1Mb
EPUB - 0.5Mb