This is the final release of MySQL 5.5 for which Generic Linux MySQL binary packages built with the icc compiler on x86 and x86_64 will be offered. These were previously produced as an alternative to our main packages built using gcc, as they provided noticeable performance benefits. In recent times the performance differences have diminished and build and runtime problems have surfaced, thus it is no longer viable to continue producing them.

We continue to use the icc compiler to produce our distribution-specific RPM packages on ia64.

InnoDB has been upgraded to version 1.1.1. This version is considered of “early adopter” quality.

InnoDB is now the default storage engine, rather than MyISAM, in the regular and enterprise versions of MySQL. This change has the following consequences:

Follow these steps to ensure a smooth transition:

Incompatible Change: All numeric operators and functions on integer, floating-point and DECIMAL values now throw an “out of range” error (ER_DATA_OUT_OF_RANGE) rather than returning an incorrect value or NULL, when the result is out of the supported range for the corresponding data type. See Section 10.6, “Out-of-Range and Overflow Handling”. (Bug#8433)

InnoDB Storage Engine: The INFORMATION_SCHEMA.INNODB_TRX table now includes a number of new fields that duplicate information from the SHOW ENGINE INNODB STATUS output. You no longer need to parse that output to get complete transaction information. (Bug#53336)

InnoDB Storage Engine: InnoDB stores redo log records in a hash table during recovery. On 64-bit systems, this hash table was 1/8 of the buffer pool size. To reduce memory usage, the dimension of the hash table was reduced to 1/64 of the buffer pool size (or 1/128 on 32-bit systems). (Bug#53122)

Previously, the innodb_file_format_check system variable served a dual purpose. Setting it at server startup would keep InnoDB from starting if any tables used a more recent file format than supported by the current level of InnoDB. If InnoDB could start, the same system variable was set to the “highest” file format value used by any InnoDB table in the database. Thus, its value could change from the value you specified.

Now, checking and recording the file format tag are handled using separate variables. innodb_file_format_check can be set to 1 or 0 at server startup to enable or disable whether InnoDB checks the file format tag in the system tablespace. If the tag is checked and is higher than that supported by the current version of InnoDB, an error occurs and InnoDB does not start. If the tag is not higher, InnoDB sets the value of innodb_file_format_max to the file format tag.

For background information about InnoDB file-format management, see Section 13.7.4, “InnoDB File Format Management”. (Bug#49792, Bug#53654)

The Rows_examined value in slow query log rows now is nonzero for UPDATE and DELETE statements that modify rows. (Bug#49756)

The deprecated mysql_fix_privilege_tables script has been removed. (Bug#42589)

There is a new system variable, skip_name_resolve, that is set from the value of the --skip-name-resolve server option. This provides a way to determine at runtime whether the server uses name resolution for client connections. (Bug#37168)

Added the SHA2() function, which calculates the SHA-2 family of hash functions (SHA-224, SHA-256, SHA-384, and SHA-512). (Contributed by Bill Karwin) (Bug#13174)

It is now possible to build MySQL on all platforms using CMake instead of the GNU autotools. (Prior to MySQL 5.5.5, CMake support was limited to Windows.) For instructions on using CMake to build MySQL, see http://forge.mysql.com/wiki/CMake.

Performance: InnoDB Storage Engine: Deadlock detection could be a bottleneck in InnoDB processing, if many transactions attempted to update the same row simultaneously. The algorithm has been improved to enhance performance and scalability, in the InnoDB Plugin for MySQL 5.1, and in InnoDB 1.1 for MySQL 5.5. (Bug#49047)

Performance: While looking for the shortest index for a covering index scan, the optimizer did not consider the full row length for a clustered primary key, as in InnoDB. Secondary covering indexes will now be preferred, making full table scans less likely. (Bug#39653)

See also Bug#55656.

Security Fix: The server could crash if there were alternate reads from two indexes on a table using the HANDLER interface. (Bug#54007, CVE-2010-3681)

Security Fix: The server failed to check the table name argument of a COM_FIELD_LIST command packet for validity and compliance to acceptable table name standards. This could be exploited to bypass almost all forms of checks for privileges and table-level grants by providing a specially crafted table name argument to COM_FIELD_LIST.

In MySQL 5.0 and above, this permitted an authenticated user with SELECT privileges on one table to obtain the field definitions of any table in all other databases and potentially of other MySQL instances accessible from the server's file system.

Additionally, for MySQL version 5.1 and above, an authenticated user with DELETE or SELECT privileges on one table could delete or read content from any other table in all databases on this server, and potentially of other MySQL instances accessible from the server's file system. (Bug#53371, CVE-2010-1848)

Security Fix: The server was susceptible to a buffer-overflow attack due to a failure to perform bounds checking on the table name argument of a COM_FIELD_LIST command packet. By sending long data for the table name, a buffer is overflown, which could be exploited by an authenticated user to inject malicious code. (Bug#53237, CVE-2010-1850)

Security Fix: LOAD DATA INFILE did not check for SQL errors and sent an OK packet even when errors were already reported. Also, an assert related to client/server protocol checking in debug servers sometimes was raised when it should not have been. (Bug#52512, CVE-2010-3683)

Security Fix: Privilege checking for UNINSTALL PLUGIN was incorrect. (Bug#51770, CVE-2010-1621)

Security Fix: The server could be tricked into reading packets indefinitely if it received a packet larger than the maximum size of one packet. (Bug#50974, CVE-2010-1849)

Incompatible Change: TRUNCATE TABLE did not take an exclusive lock on a table if truncation was done by deleting all rows in the table. For InnoDB tables, this could break proper isolation because InnoDB ended up aborting some granted locks when truncating a table. Now an exclusive metadata lock is taken before TRUNCATE TABLE can proceed. This guarantees that no other transaction is using the table.

Incompatible change: Truncation using delete no longer fails if sql_safe_updates is enabled (this was an undocumented side effect). (Bug#42643)

Incompatible Change: After SET TRANSACTION ISOLATION LEVEL to set the isolation level for the next transaction, the session value of the tx_isolation system variable could appear to change after completion of statements within the transaction to the transaction isolation level. Now the current transaction isolation level is now established at transaction start. If there was a SET TRANSACTION ISOLATION LEVEL statement, the value is taken from it. Otherwise, the session tx_isolation value is used. A change in the session value while a transaction is active is still allowed, but no longer affects the current transaction isolation level. This is an incompatible change. A change in the session isolation level made while there is no active transaction overrides a SET TRANSACTION ISOLATION LEVEL statement, if there was any. (Bug#20837)

Important Change: Replication: It was possible to set sql_log_bin with session scope inside a transaction or subquery. (Bug#53437)

Important Change: Replication: When changing binlog_format or binlog_direct_non_transactional_updates, permissions were not checked prior to checking the scope and context of the variable being changed.

As a result of this fix, an error is no longer reported when—in the context of a transaction or a stored function—you try to set a value for a session variable that is the same as its previous value, or for a variable whose scope is global only. (Bug#51277)

Important Change: Replication: When invoked, CHANGE MASTER TO and SET GLOBAL sql_slave_skip_counter now cause information to be written to the error log about the slave's state prior to execution of the statement. For CHANGE MASTER TO, this information includes the previous values of MASTER_HOST, MASTER_PORT, MASTER_LOG_FILE, and MASTER_LOG_POS. For SET GLOBAL sql_slave_skip_counter, this information includes the previous values of RELAY_LOG_FILE, RELAY_LOG_POS, and sql_slave_skip_counter. (Bug#43406, Bug#43407)

Important Change: When using fast ALTER TABLE, different internal ordering of indexes in the MySQL optimizer and the InnoDB storage engine could cause error messages about possibly mixed up .frm files and incorrect index use. (Bug#47622)

InnoDB Storage Engine: Replication: TRUNCATE TABLE performed on a temporary table using the InnoDB storage engine was logged even when using row-based mode. (Bug#51251)

InnoDB Storage Engine: Replication: Reading from a table that used a self-logging storage engine and updating a table that used a transactional engine (such as InnoDB) generated changes that were written to the binary log using statement format which could make slaves diverge. However, when using mixed logging format, such changes should be written to the binary log using row format. (This issue did not occur when reading from tables using a self-logging engine and updating MyISAM tables, as this was already handled by checking for combinations of non-transactional and transactional engines.) Now such statements are classified as unsafe, and in mixed mode, cause a switch to row-based logging. (Bug#49019)

InnoDB Storage Engine: The server could crash during shutdown, if started with the option --innodb_use_sys_malloc=0. (Bug#54453)

InnoDB Storage Engine: The server could crash with a message InnoDB: Assertion failure in thread nnnn, typically during shutdown on a Windows system. (Bug#53947)

InnoDB Storage Engine: Some combinations of SELECT and SELECT FOR UPDATE statements could fail with errors about locks, or incorrectly release a row lock during a semi-consistent read operation. (Bug#53674)

InnoDB Storage Engine: Adding a unique key on multiple columns, where one of the columns is null, could mistakenly report duplicate key errors. (Bug#53290)

InnoDB Storage Engine: Fixed a checksum error reported for compressed tables when the --innodb_checksums option is enabled. Although the message stated that the table was corrupted, the table is actually fine after the fix. (Bug#53248)

InnoDB Storage Engine: When reporting a foreign key constraint violation during INSERT, InnoDB could display uninitialized data for the DB_TRX_ID and DB_ROLL_PTR system columns. (Bug#53202)

InnoDB Storage Engine: The values of innodb_buffer_pool_pages_total and innodb_buffer_pool_pages_misc in the information_schema.global_status table could be computed incorrectly. (Bug#52983)

InnoDB Storage Engine: InnoDB page splitting could enter an infinite loop for compressed tables. (Bug#52964)

InnoDB Storage Engine: An overly strict assertion could fail during the purge of delete-marked records in DYNAMIC or COMPRESSED InnoDB tables that contain column prefix indexes. (Bug#52746)

InnoDB Storage Engine: InnoDB attempted to choose off-page storage without ensuring that there was an “off-page storage” flag in the record header. To correct this, in DYNAMIC and COMPRESSED formats, InnoDB stores locally any non-BLOB columns having a maximum length not exceeding 256 bytes. This is because there is no room for the “external storage” flag when the maximum length is 255 bytes or less. This restriction trivially holds in REDUNDANT and COMPACT formats, because there InnoDB always stores locally columns having a length up to local_len = 788 bytes. (Bug#52745)

InnoDB Storage Engine: Connections waiting for an InnoDB row lock ignored KILL until the row lock wait ended. Now, KILL during lock wait results in “query interrupted” instead of “lock wait timeout exceeded”. The corresponding transaction is rolled back. (Bug#51920)

InnoDB Storage Engine: InnoDB checks to see whether a row could possibly exceed the maximum size if all columns are fully used. This produced Row size too large errors for some tables that could be created with the built-in InnoDB from older MySQL versions. Now the check is only done when innodb_strict_mode is enabled or if the table is dynamic or compressed. (Bug#50495)

InnoDB Storage Engine: Multi-statement execution could fail with an error about foreign key constraints. This problem could affect calls to mysql_query() and mysql_real_query(), and CALL statements that invoke stored procedures. (Bug#48024)

InnoDB Storage Engine: A mismatch between index information maintained within the .frm files and the corresponding information in the InnoDB system tablespace could produce this error: [ERROR] Index index of table has n columns unique inside InnoDB, but MySQL is asking statistics for m columns. Have you mixed up .frm files from different installations? (Bug#44571)

Partitioning: Replication: Attempting to execute LOAD DATA on a partitioned MyISAM table while using statement-based logging mode caused the master to hang or crash. (Bug#51851)

Partitioning: Replication: The NO_DIR_IN_CREATE server SQL mode was not enforced when defining subpartitions. In certain cases, this could lead to failures on replication slaves. (Bug#42954)

Partitioning: Rows inserted into a table created using a PARTITION BY LIST COLUMNS option referencing multiple columns could be inserted into the wrong partition. (Bug#52815)

Partitioning: Partition pruning on RANGE partitioned tables did not always work correctly; the last partition was not excluded if the range was beyond it (when not using MAXVALUE). Now the last partition is not included if the partitioning function value is not within the range. (Bug#51830)

Partitioning: Attempting to partition a table using a DECIMAL column caused the server to crash; this not supported and is now specifically not permitted. (Bug#51347)

Partitioning: ALTER TABLE statements that cause table partitions to be renamed or dropped (such as ALTER TABLE ... ADD PARTITION, ALTER TABLE ... DROP PARTITION, and ALTER TABLE ... REORGANIZE PARTITION) — when run concurrently with queries against the INFORMATION_SCHEMA.PARTITIONS table — could fail, cause the affected partitioned tables to become unusable, or both. This was due to the fact that the INFORMATION_SCHEMA database ignored the name lock imposed by the ALTER TABLE statement on the partitions affected. In particular, this led to problems with InnoDB tables, because InnoDB would accept the rename operation, but put it in a background queue, so that subsequent rename operations failed when InnoDB was unable to find the correct partition. Now, INFORMATION_SCHEMA honors name locks imposed by ongoing ALTER TABLE statements that cause partitions to be renamed or dropped. (Bug#50561)

See also Bug#47343, Bug#45808.

Partitioning: The insert_id server system variable was not reset following an insert that failed on a partitioned MyISAM table having an AUTO_INCREMENT column. (Bug#50392)

Partitioning: Foreign keys are not supported on partitioned tables. However, it was possible using an ALTER TABLE statement to set a foreign key on a partitioned table; it was also possible to partition a table with a single foreign key. (Bug#50104)

Partitioning: It was possible to execute a CREATE TEMPORARY TABLE tmp LIKE pt statement, where pt is a partitioned table, even though partitioned temporary tables are not permitted, which caused the server to crash. Now a check is performed to prevent such statements from being executed. (Bug#49477)

Partitioning: When attempting to perform DDL on a partitioned table and the table's .par file could not be found, the server returned the inaccurate error message Out of memory; restart server and try again (needed 2 bytes). Now in such cases, the server returns the error Failed to initialize partitions from .par file. (Bug#49161)

Partitioning: GROUP BY queries performed poorly for some partitioned tables. This was due to the block size not being set for partitioned tables, thus the keys per block was not correct, which could cause such queries to be optimized incorrectly. (Bug#48229)

See also Bug#37252.

Partitioning: REPAIR TABLE failed for partitioned ARCHIVE tables. (Bug#46565)

Replication: When using unique keys on NULL columns in row-based replication, the slave sometimes chose the wrong row when performing an update. This happened because a table having a unique key on such a column could have multiple rows containing NULL for the column used by the unique key, and the slave merely picked the first row containing NULL in that column. (Bug#53893)

Replication: When a CREATE TEMPORARY TABLE ... SELECT statement was executed within a transaction that updated only transactional engines and was later rolled back (for example, due to a deadlock) the changes—including the creation of the temporary table—were not written to the binary log, which caused subsequent updates to this table to fail on the slave. (Bug#53421)

Replication: When using the statement-based logging format, statements that used CONNECTION_ID() were always kept in the transaction cache; consequently, nontransactional changes that should have been flushed before the transaction were kept in the transaction cache. (Bug#53075)

This regression was introduced by Bug#51894.

Replication: In some cases, attempting to update a column with a value of an incompatible type resulted in a mismatch between master and slave because the column value was set to its implicit default value on the master (as expected), but the same column on the slave was set to NULL. (Bug#52868)

Replication: ACK packets in semisynchronous replication were not checked for length and malformed packets could cause a server crash. (Bug#52748)

Replication: When temporary tables were in use, switching the binary logging format from STATEMENT to ROW did not take effect until all temporary tables were dropped. (The existence of temporary tables should prevent switching the format only from ROW to STATEMENT from taking effect, not the reverse.) (Bug#52616)

Replication: A buffer overrun in the handling of DATE column values could cause mysqlbinlog to fail when reading back logs containing certain combinations of DML on a table having a DATE column followed by dropping the table. (Bug#52202)

Replication: The failure of a REVOKE statement was logged with the wrong error code, causing replication slaves to stop even when the failure was expected on the master. (Bug#51987)

Replication: Issuing any DML on a temporary table temp followed by DROP TEMPORARY TABLE temp, both within the same transaction, caused replication to fail.

The fix introduces a change to statement-based binary logging with respect to temporary tables. Within a transaction, changes to temporary tables are saved to the transaction cache and written to the binary log when the transaction commits. Otherwise, out-of-order logging of events could occur. This means that temporary tables are treated similar to transactional tables for purposes of caching and logging. This affects assessment of statements as safe or unsafe and the associated error message was changed from:

Unsafe statement written to the binary log using statement format
since BINLOG_FORMAT = STATEMENT. Statements that read from both
transactional and non-transactional tables and write to any of them
are unsafe.

To:

Unsafe statement written to the binary log using statement format
since BINLOG_FORMAT = STATEMENT. Statements that read from both
transactional (or a temporary table of any engine type) and
non-transactional tables and write to any of them are unsafe.

(Bug#51894)

See also Bug#51291, Bug#53075, Bug#53259, Bug#53452, Bug#54872.

This regression was introduced by Bug#46364.

Replication: The flag stating whether a user value was signed or unsigned (unsigned_flag) could sometimes change between the time that the user value was recorded for logging purposes and the time that the value was actually written to the binary log, which could lead to inconsistency. Now unsigned_flag is copied when the user variable value is copied, and the copy of unsigned_flag is then used for logging. (Bug#51426)

See also Bug#49562.

Replication: Enabling binlog_direct_non_transactional_updates causes nontransactional changes to be written to the binary log upon committing the statement. However, even when not enabled, the addition of this variable introduced a number of undesired changes in behavior:

These problems have been handled as follows:

(Bug#51291)

This regression was introduced by Bug#46364.

Replication: When using temporary tables the binary log needs to insert a pseudo-thread ID for threads that are using temporary tables, each time a switch happens between two threads, both of which are using temporary tables. However, if a thread issued a failing statement before exit, its ID was not recorded in the binary log, and this in turn caused the ID for the next thread that tried to do something with a temporary table not to be logged as well. Subsequent replays of the binary log failed with the error Table ... doesn't exist. (Bug#51226)

Replication: If the master was using sql_mode='TRADITIONAL', duplicate key errors were not sent to the slave, which received 0 rather than the expected error code. This caused replication to fail even when such an error was expected. (Bug#51055)

Replication: DDL statements that lock tables (such as ALTER TABLE, CREATE INDEX, and CREATE TRIGGER) caused spurious ER_BINLOG_ROW_MODE_AND_STMT_ENGINE or ER_BINLOG_STMT_MODE_AND_ROW_ENGINE errors, even though they did not insert rows into any tables.

(Bug#50479)

This regression was introduced by Bug#39934.

Replication: When run with the --database option, mysqlbinlog printed ROLLBACK statements but did not print any corresponding SAVEPOINT statements. (Bug#50407)

Replication: When a CREATE EVENT statement was followed by an additional statement and the statements were executed together as a single statement, the CREATE EVENT statement was padded with “garbage” characters when written to the binary log, which led to a syntax error when trying to read back from the log. (Bug#50095)

Replication: When using a non-transactional table on the master with autocommit disabled, no COMMIT was recorded in the binary log following a statement affecting this table. If the slave's copy of the table used a transactional storage engine, the result on the slave was as though a transaction had been started, but never completed. (Bug#49522)

See also Bug#29288.

The make_binary_distribution target to make could fail on some platforms because the lines generated were too long for the shell. (Bug#54590)

Inconsistent checking of the relationship between SHOW statements and INFORMATION_SCHEMA queries caused such queries to fail sometimes. (Bug#54422)

A crash occurred if a table that was locked with LOCK TABLES was listed twice in a DROP TABLE statement. (Bug#54282)

ALTER TABLE for views is not legal but did not produce an error. (If you need to rename a view, use RENAME TABLE.) (Bug#53976)

Valgrind warnings resulting from passing incomplete DATETIME values to the TIMESTAMP() function were corrected. (Bug#53942)

Builds of the embedded mysqld would fail due to a missing element of the struct NET. (Bug#53908, Bug#53912)

The definition of the MY_INIT macro in my_sys.h included an extraneous semicolon, which could cause compilation failure. (Bug#53906)

Queries that used MIN() or MAX() on indexed columns could be optimized incorrectly. (Bug#53859)

UPDATE on an InnoDB table modifying the same index that was used to satisfy the WHERE condition could trigger a debug assertion under some circumstances. (Bug#53830)

MySQL incorrectly processed ALTER DATABASE `#mysql50#<special>` UPGRADE DATA DIRECTORY NAME where <special> was ., .., or a sequence starting with ./ or ../. It used the server data directory (that contains other regular databases) as the database directory. (Bug#53804, CVE-2010-2008)

OPTIMIZE TABLE could be run on a table in use by a transaction in a different session, causing repeatable read to break. (Bug#53798)

InnoDB crashed when replacing duplicates in a table after a fast ALTER TABLE added a unique index. (Bug#53592)

For InnoDB tables, the error handler for a fast CREATE INDEX did not reset the error state of the transaction before attempting to undo a failed operation, resulting in a crash. (Bug#53591)

For single-table DELETE statements that used quick select and index scan simultaneously caused a server crash or assertion failure. (Bug#53450)

Certain path names passed to LOAD_FILE() could cause a server crash. (Bug#53417)

If the completion_type session variable was changed after a stored procedure or prepared statement had been cached, the change had no effect on subsequent executions of the procedure or statement. (Bug#53346)

The AND CHAIN option for COMMIT and ROLLBACK failed to preserve the current transaction isolation level. Setting completion_type to 1 also failed to do so. (Bug#53343)

Incorrect results could be returned for LEFT JOIN of InnoDB tables with an impossible WHERE condition. (Bug#53334)

The Lock_time value in the slow query log was negative for stored routines. (Bug#53191)

Setting the innodb_change_buffering system variable to DEFAULT produced an incorrect result. (Bug#53165)

mysqldump and SELECT ... INTO OUTFILE truncated long BLOB and TEXT values to 766 bytes. (Bug#53088)

On some systems, such as Mac OS X, the sockaddr_in and sockaddr_in6 structures contain a non-standard field (sin_len / sin6_len) that must be set but was not. This resulted in hostname lookup failure. (Bug#52923)

In the debug version of the server, the FreeState() function could in some circumstances be called twice, leading to an assertion failure. (Bug#52884)

Concurrent SHOW COLUMNS statements could cause a server crash. (Bug#52856)

With a non-latin1 ASCII-based current character set, the server inappropriately converted DATETIME values to strings. This resulted in the optimizer not using indexes on such columns. (Bug#52849)

mysqld_safe set plugin_dir using a default path name rather than a path depending on basedir. (Bug#52737)

Semi-consistent read was implemented for InnoDB to address Bug#3300. Semi-consistent reads do not block when a nonmatching record is already locked by some other transaction. If the record is not locked, a lock is acquired, but is released if the record does not match the WHERE condition. However, semi-consistent read was attempted even for UPDATE statements having a WHERE condition of the form pk_col1=constant1, ..., pk_colN=constantN. Some code that was designed with the assumption that semi-consistent read would be only attempted on table scans, failed. (Bug#52663)

Setting @@GLOBAL.debug to an empty string failed to clear the current debug settings. (Bug#52629)

SHOW CREATE TABLE was blocked if the table was write locked by another session. (Bug#52593)

The length and max_length metadata values were incorrect for columns with the TEXT family of data types that used multibyte character sets This bug was introduced in MySQL 5.5.3. (Bug#52520)

mysql_upgrade attempted to work with stored routines before they were available. (Bug#52444)

The check_table_is_closed() debugging function did not protect access to the MyISAM open tables list, with the result that server crashes could occur during table drop or rename operations. (Bug#52432)

Spurious duplicate-key errors occurred for multiple-column indexes on columns with the BINARY data type. (Bug#52430)

EXPLAIN EXTENDED crashed trying to resolve references to freed temporary table columns for GROUP_CONCAT() ORDER BY arguments. (Bug#52397)

During installing of MySQL server using the MSI package on Windows, the default-character-set option would be included in the default configuration template file. This would cause the MySQL server to fail to start properly. (Bug#52380)

Two sessions trying to set the global event_scheduler system variable to OFF resulted in one of them hanging waiting for the event scheduler to stop. (Bug#52367)

There was a race condition between flags used for signaling that a query was killed, which led to error-reporting and lock-acquisition problems. (Bug#52356)

For a concurrent load of 16 or more connections containing many LOCK TABLES WRITE statements for the same table, server throughput was significantly lower for MySQL 5.5.3 and 5.5.4 than for earlier versions (10%–40% lower depending on concurrency). (Bug#52289)

Operations on geometry data types failed on some systems for builds compiled with Sun Studio. (Bug#52208)

The optimizer could attempt to evaluate the WHERE clause before any rows had been read, resulting in a server crash. (Bug#52177)

Cast operations on NULL DECIMAL values could cause server crashes or Valgrind warnings. (Bug#52168)

An assertion was raised as a result of a NULL string being passed to the dtoa code. (Bug#52165)

A memory leak occurred due to missing deallocation of the comparators array (a member of the Arg_comparator class). (Bug#52124)

For debug builds, creating a view containing a subquery that might require collation adjustment caused an assertion to be raised. For example, this could occur if some items had different collations but the result collation could be adjusted to the one of them. (Bug#52120)

Aggregate functions could incorrectly return NULL in outer join queries. (Bug#52051)

For outer joins, the optimizer could fail to properly calculate table dependencies. (Bug#52005)

A COUNT(DISTINCT) query on a view could cause a server crash. (Bug#51980)

For LDML-defined collations, some data structures were not initialized properly to enable UPPER() and LOWER() to work correctly. (Bug#51976)

On Windows, LOAD_FILE() could cause a crash for some pathnames. (Bug#51893)

Invalid memory reads occurred for HANDLER ... READ NEXT after a failed HANDLER ... READ FIRST. (Bug#51877)

After TRUNCATE TABLE of a MyISAM table, subsequent queries could crash the server if myisam_use_mmap was enabled. (Bug#51868)

If myisam_sort_buffer_size was set to a small value, table repair for MyISAM tables with FULLTEXT indexes could crash the server. (Bug#51866)

Stored routine DDL statements were written to the binary log using statement-based format regardless of the current logging format. (Bug#51839)

A problem with equality propagation optimization for prepared statements and stored procedures caused a server crash upon re-execution of the prepared statement or stored procedure. (Bug#51650)

See also Bug#8115, Bug#8849.

The optimizer performed an incorrect join type when COALESCE() appeared within an IN() operation. (Bug#51598)

Locking involving the LOCK_plugin, LOCK_global_system_variables, and LOCK_status mutexes could deadlock. (Bug#51591)

Executing a LOAD XML INFILE statement could sometimes lead to a crash of the MySQL Server. (Bug#51571)

The server crashed when the optimizer attempted to determine constant tables but a table storage engine did not support exact record count. (Bug#51494)

The server could crash populating the INFORMATION_SCHEMA.PROCESSLIST table due to lack of mutex protection. (Bug#51377)

Use of HANDLER statements with tables that had spatial indexes caused a server crash. (Bug#51357)

With an XA transaction active, SET autocommit = 1 could cause side effects such as memory corruption or a server crash. (Bug#51342)

Corrupt MyISAM tables were automatically repaired even when myisam_recover_options was set to OFF. (Bug#51327)

Following a bulk insert into a MyISAM table, if MyISAM failed to build indexes using repair by sort, data file corruption could occur. (Bug#51307)

CHECKSUM TABLE could compute the checksum for BIT columns incorrectly. (Bug#51304)

ALTER TABLE on InnoDB tables (including partitioned tables) acquired exclusive locks on rows of the table being altered. If there was a concurrent transaction that did locking reads from this table, this sometimes led to a deadlock that was not detected by the metadata lock subsystem or by InnoDB (and was reported only after exceeding innodb_lock_wait_timeout). (Bug#51263)

A HAVING clause on a joined table in some cases failed to eliminate rows which should have been excluded from the result set. (Bug#51242)

Two sessions trying to set the global event_scheduler system variable to different values could deadlock. (Bug#51160)

InnoDB fast index creation could incorrectly use a table copy in some cases. (Bug#50946)

The Loose Index Scan optimization method assumed that it could depend on the partitioning engine to maintain interval endpoint information, as if it were a storage engine. (Bug#50939)

The type inference used for view columns caused some columns in views to be handled as the wrong type, as compared to the same columns in base tables. DATE columns in base tables were treated as TIME columns in views, and base table TIME columns as view DATETIME columns. (Bug#50918)

A syntactically invalid trigger could cause the server to crash when trying to list triggers. (Bug#50755)

Previously, the server held a global mutex while performing file operations such as deleting an .frm or data file, or reading table metadata from an .frm file or index statistics from a data file. Now the mutex is not held for these operations. Instead, the server uses metadata locks. (Bug#50589, Bug#51557, Bug#49463)

User-defined variables of type REAL that contained NULL were handled improperly when assigned to a column of another type. (Bug#50511)

Setting --secure-file-priv to the empty string left the value unaffected. (Bug#50373)

Calculation of intervals for Event Scheduler events was not portable. (Bug#50087)

The YEAR values 2000 and 0000 could be treated as equal. (Bug#49910)

Performing a single in-place ALTER TABLE containing ADD INDEX and DROP INDEX options that used the same index name could result in a corrupt table definition file. Now such ALTER TABLE statements are no longer performed in place. (Bug#49838)

mysql_upgrade did not detect when CSV log tables incorrectly contained columns that could be NULL. Now these columns are altered to be NOT NULL. (Bug#49823)

support-files/mysql.spec.sh had unnecessary Perl dependencies. (Bug#49723)

Selecting from INFORMATION_SCHEMA.ROUTINES or INFORMATION_SCHEMA.PARAMETERS resulted in a memory leak. (Bug#48729)

In MySQL 5.1, READ COMMITTED was changed to use less locking due to the availability of row based binary logging (see the Note under READ COMMITTED at Section 12.3.6, “SET TRANSACTION Syntax”). However, READ UNCOMMITTED did not have the same change, so it was using more locks than the higher isolation level, which is unexpected. This was changed so that READ UNCOMMITTED now also uses the lesser amount of locking and has the same restrictions for binary logging. (Bug#48607)

On Intel x86 machines, the optimizer could choose different execution plans for a query depending on the compiler version and optimization flags used to build the server binary. (Bug#48537)

A trigger could change the behavior of assigning NULL to a NOT NULL column. (Bug#48525)

The server crashed when it could not determine the best execution plan for queries involving outer joins with nondeterministic ON clauses such as the ones containing the RAND() function, a user-defined function, or a NOT DETERMINISTIC stored function. (Bug#48483)

EXPLAIN could cause a server crash for some queries with subqueries. (Bug#48419)

The MERGE engine failed to open a child table from a different database if the child table or database name contained characters that were the subject of table name to filename encoding.

Further, the MERGE engine did not properly open a child table from the same database if the child table name contained characters such as '/', '#'. (Bug#48265)

On Windows, the server failed to find a description for Event ID 100. (Bug#48042)

A query that read from a derived table (of the form SELECT ... FROM (SELECT ...)) produced incorrect results when the following conditions were present:

(Bug#47904)

The optimization to read MIN() or MAX() values from an index did not properly handle comparisons with NULL values. This could produce incorrect results for MIN() or MAX()when the WHERE clause tested a NOT NULL column for NULL. (Bug#47762)

Killing a query during the optimization phase of a subquery could cause a server crash. (Bug#47761)

Using REPLACE to update a previously inserted negative value in an AUTO_INCREMENT coumn in an InnoDB table caused the table auto-increment value to be updated to 2147483647. (Bug#47720)

The query shown by EXPLAIN EXTENDED plus SHOW WARNINGS could produce results different from the original query. (Bug#47669)

MyISAM could write uninitialized data to new index pages. Now zeros are written to unused bytes in the pages. (Bug#47598)

OPTIMIZE TABLE for an InnoDB table could raise an assertion if another session issued a concurrent DROP TABLE. (Bug#47459)

For updates to InnoDB tables, TIMESTAMP columns could be updated even when no values actually changed. (Bug#47453)

Setting myisam_repair_threads larger than 1 could result in the cardinality for all indexes of a MyISAM table being set to 1 after parallel index repair. (Bug#47444)

mysqld_safe did not always pass --open-files-limit through to mysqld. mysqld_safe did not treat dashes and underscores as equivalent in option names. (Bug#47095)

For events of MYSQL_AUDIT_GENERAL_CLASS, the event subclass was not passed to audit plugins even though the server passed the subclass to the plugin handler. The subclass is now available through the following changes:

The example plugin in the plugin/audit_null directory has been modified to count events of each subclass, based on the event_subclass value. See Section 23.2.5.2, “Writing Audit Plugins”. (Bug#47059)

When the transaction isolation level was REPEATABLE READ and binary logging used statement or mixed format, SELECT statements with subqueries referencing InnoDB tables unnecessarily acquired shared locks on rows in these tables. (Bug#46947)

In debug builds, if the listed columns in the view definition of the table used in an INSERT ... SELECT statement mismatched, an assertion was raised in the query cache invalidation code following the failing statement. (Bug#46615)

For the COMMIT and ROLLBACK statements, the AND CHAIN and RELEASE modifiers should be mutually exclusive, but the parser allowed both to be specified. (Bug#46527)

If the server is started with --skip-grant-tables, plugin loading and unloading should be prohibited, but the server failed to reject INSTALL PLUGIN and UNINSTALL PLUGIN statements. (Bug#46261)

gcc 4.4.0 could fail to compile dtoa.c. (Bug#45882)

ALTER TABLE ... ADD COLUMN for a table with multiple foreign keys caused a server crash. (Bug#45052)

Manual pages for a few little-used programs were missing from RPM packages. (Bug#44370)

Using an initial command with mysql_options(..., MYSQL_INIT_COMMAND, ...) that generated multiple result sets (such as a stored procedure or a multi-statement command) left the connection unusable. (Bug#42373)

The server could crash with an out of memory error when trying to parse a query that was too long to fit in memory. Now the parser rejects such queries with an ER_OUT_OF_RESOURCES error. (Bug#42064)

InnoDB could fail to create a unique index on NULL columns. (Bug#41904)

For a query that selected from a view and used an alias for the view, the metadata used the alias name rather than the view name in the MYSQL_FIELD.table member. (Bug#41788)

mysql_upgrade did not create temporary files properly. (Bug#41057)

It was possible for DROP TABLE of one MyISAM table to remove the data and index files of a different MyISAM table. (Bug#40980)

If the arguments to a CONCAT() call included a local routine variable, selecting the return value into a user variable could produce an incorrect result. (Bug#40625)

Column names displayed from the PARTITION_EXPRESSION column of the INFORMATION_SCHEMA.PARTITIONS table did not include escape characters as necessary. (Bug#39338)

When SET TRANSACTION ISOLATION LEVEL was used to set the isolation level for the next transaction, the level could persist for subsequent transactions. (Bug#39170)

When using UNINSTALL PLUGIN to remove a loaded plugin, open tables and connections caused mysqld to hang until the open connections had been closed. (Bug#39053)

Valgrind warnings in the InnoDB compare_record() function were corrected. (Bug#38999)

The optimizer sometimes used filesort for ORDER BY when it should have used an index. (Bug#38745)

Setting the session value of the debug system variable also set the global value. (Bug#38054)

Accessing a MERGE table with an empty underlying table list incorrectly resulted in a “wrong index” error message rather than “end of file.” (Bug#35274)

The test for readline during configuration failed when trying to build MySQL in a directory other than the source tree root. (Bug#35250)

mysqld could fail during execution when using SSL. (Bug#34236)

A query on a FEDERATED table in which the data was ordered by a TEXT column returned incorrect results. For example, a query such as the following would result in incorrect results if column column1 was a TEXT column:

SELECT * FROM table1 ORDER BY column1;

(Bug#32426)

MySQL Makefiles relied on GNU extensions. (Bug#30708)

The parser allocated too much memory for a query containing multiple statements. (Bug#27863)

The behavior of the RPM installation for both new installations and upgrade installations has changed.

During a new installation, the server boot scripts are installed, but the MySQL server is not started at the end of the installation, since the status of the system during an unattended installation is not known.

During an upgrade installation using the RPM packages, if the server is running when the upgrade occurs, the server is stopped, the upgrade occurs, and server is restarted. If the server is not already running when the RPM upgrade occurs, the server is not started at the end of the installation.

The boot scripts for MySQL are installed in the appropriate directories in /etc, so the MySQL server will be restarted automatically at the next machine reboot. (Bug#27072)

ROW_COUNT() returned a meaningful value only for some DML statements. Now it returns a value as follows:

(Bug#21818)