Appendix C. MySQL Change History

The time zone tables for Windows available at timezones.html have been updated. (Bug#39923)

The mysqltest program now has a move_file from_file to_file command for renaming files. This should be used in test cases rather than invoking an external command that might be platform specific. (Bug#39542)

Important Change: Replication: The CHANGE MASTER TO statement required the value for RELAY_LOG_FILE to be an absolute path, while the MASTER_LOG_FILE path could be relative.

The inconsistent behavior is resolved by allowing relative paths for RELAY_LOG_FILE, and by using the same basename for RELAY_LOG_FILE as for MASTER_LOG_FILE. For more information, see Section 12.6.2.1, “CHANGE MASTER TO Syntax”. (Bug#12190)

Important Change: Replication: The transactional behavior of STOP SLAVE has changed. Formerly, it took effect immediately, even inside a transaction; now, it waits until the current replication event group (if any) has finished executing, or until the user issues a KILL QUERY or KILL CONNECTION statement.

This was done in order to solve the problem encountered when replication was stopped while a nontransactional slave was replicating a transaction on the master. (It was impossible to roll back a mixed-engines transaction when one of the engines was nontransactional, which meant that the slave could not safely re-apply any transaction that had been interrupted by STOP SLAVE.) (Bug#319, Bug#38205)

See also Bug#43217.

Important Change: An option that requires a value, when specified in an option file without a value, was assigned the text of the next line in the file as the value. Now, if you fail to specify a required value in an option file, the server aborts with an error.

This change does not effect how options are handled by the server when they are used on the command line. For example, starting the server using mysqld_safe --relay-log --relay-log-index & causes the server to create relay log files named --relay-log-index.000001, --relay-log-index.000002, and so on, because the --relay-log option expects an argument. (Bug#25192)

Partitioning: When a value was equal to a PARTITION ... VALUES LESS THAN (value) value other than MAXVALUE, the corresponding partition was not pruned. (Bug#42944)

Replication: Issuing the following statements, in the order shown, could cause a deadlock between the user thread and I/O thread:

START SLAVE;
STOP SLAVE SQL_THREAD;
START SLAVE;

(Bug#44312)

See also Bug#38715, Bug#38716.

Replication: Unrelated errors occurring during the execution of RESET SLAVE could cause the slave to crash. (Bug#44179)

Replication: When using semi-synchronous replication:

(Bug#44058)

See also Bug#40935.

Replication: Replicating TEXT or VARCHAR columns declared as NULL on the master but NOT NULL on the slave caused the slave to crash. (Bug#43789)

See also Bug#38850, Bug#43783, Bug#43785.

Replication: Executing the sequence of statements RESET SLAVE, RESET MASTER, and FLUSH LOGS, when binary log or relay log files listed in the index file could not be found, could cause the server to crash. This could happen, for example, when these files had been moved or deleted manually. (Bug#41902)

Replication: MySQL creates binary logs in a numbered sequence, with a maximum possible 4294967295 concurrent log files, 4294967295 being the maximum value for an unsigned long integer. However, binary log file extensions were turned into negative numbers once the variable used to hold the value reached the maximum value for a signed long integer (2147483647). Consequently, when the sequence value was incremented to the next (negative) number, this caused MySQL to try to create the file using a .000000 extension, causing the server to fail since this file already existed.

Negative file extensions are now disallowed, and an error is returned when the limit is reached. In addition, FLUSH LOGS now also reports warnings to the user, if the extension number has reached the limit, and warnings are printed to the error log when the limit is approaching. (Bug#40611)

Replication: Updating a table having no primary key, using an unindexed CHAR column as the key, caused row-based replication to fail. (Bug#40045)

Replication: The --slave-skip-errors option had no effect when using row-based logging format. (Bug#39393)

Replication: Issuing concurrent STOP SLAVE, START SLAVE, and RESET SLAVE statements using different connections caused the replication slave to crash. (Bug#38716)

See also Bug#38715, Bug#44312.

Replication: The following erors were not correctly reported:

Information about these types of failures can now be found in the output of SHOW SLAVE STATUS. (Bug#38197)

Replication: Killing the thread executing a DDL statement, after it had finished its execution but before it had written the binlog event, caused the error code in the binlog event to be set (incorrectly) to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED, which caused replication to fail. (Bug#37145)

See also Bug#27571, Bug#22725.

Replication: Column alises used inside subqueries were ignored in the binary log. (Bug#35515)

For settings of lower_case_table_names greater than 0, some queries for INFORMATION_SCHEMA tables left entries with incorrect lettercase in the table definition cache. (Bug#44738)

Valgrind warnings for the DECODE(), ENCRYPT(), and FIND_IN_SET() functions were corrected. (Bug#44358, Bug#44365, Bug#44367)

On Windows, entries for build-vs9.bat and build-vs9_x64.bat were missing in win/Makefile.am. (Bug#44353)

Not all lock types had proper descriptive strings, resulting in garbage output from mysqladmin debug. (Bug#44164)

Use of HANDLER statements with INFORMATION_SCHEMA tables caused a server crash. Now HANDLER is prohibited with such tables. (Bug#44151)

On Windows, if the mysql client was reading input from a pipe, it could crash attempting to read after EOF. (Bug#44133)

Invoking SHOW TABLE STATUS from within a stored procedure could cause a Packets out of order error. (Bug#43962)

myisamchk could display a negative Max keyfile length value. (Bug#43950)

On 64-bit systems, a key_buffer_size value larger than 4GB could couse MyISAM index corruption. (Bug#43932)

mysqld_multi incorrectly passed --no-defaults to mysqld_safe. (Bug#43876)

SHOW VARIABLES did not properly display the value of slave_skip_errors. (Bug#43835)

On Windows, a server crash occurred for attempts to insert a floating-point value into a CHAR column with a maximum length less than the converted floating-point value length. (Bug#43833)

Incorrect initialization of MyISAM table indexes could cause incorrect query results. (Bug#43737)

libmysqld crashed when it was reinitialized. (Bug#43706, Bug#44091)

UNION of floating-point numbers did unnecessary rounding. (Bug#43432)

ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME failed when the database contained views. (Bug#43385)

Certain statements might open a table and then wait for an impending global read lock without noticing whether they hold a table being waiting for by the global read lock, causing a hang. Affected statements are SELECT ... FOR UPDATE, LOCK TABLES ... WRITE, TRUNCATE TABLE, and LOAD DATA INFILE. (Bug#43230)

Using an XML function such as ExtractValue() more than once in a single query could produce erroneous results. (Bug#43183)

See also Bug#43937.

DROP DATABASE did not clear the message list. (Bug#43012, Bug#43138)

Full-text prefix searches could hang the connection and cause 100% CPU consumption. (Bug#42907)

Comparison of TIME values could lose the sign of operands. (Bug#42664)

MAKETIME() could lose the sign of negative arguments. (Bug#42662)

SEC_TO_TIME() could lose the sign of negative arguments. (Bug#42661)

InnoDB had excessive contention for a character set mutex. (Bug#42649)

Incorrect elevation of warning messages to error messages for unsafe statements caused a server crash. (Bug#42640)

CHECK TABLE suggested use of REPAIR TABLE for corrupt tables for storage engines not supported by REPAIR TABLE. Now CHECK TABLE suggests that the user dump and reload the table. (Bug#42563)

The InnoDB btr_search_drop_page_hash_when_freed() function had a race condition. (Bug#42279)

There was a race condition when changing innodb_commit_concurrency at runtime from zero to nonzero or from nonzero to zero. Now this variable cannot be changed at runtime from zero to nonzero or vice versa. The value can still be changed from one nonzero value to another. (Bug#42101)

The state of a thread for the embedded server was always displayed as Writing to net, which is incorrect because there is no network connection for the embedded server. (Bug#41971)

Compressing a table with the myisampack utility caused the server to produce Valgrind warnings when it opened the table. (Bug#41541)

For a MyISAM table with DELAY_KEY_WRITE enabled, the index file could be corrupted without the table being marked as crashed if the server was killed. (Bug#41330)

Killing an INSERT ... SELECT statement for a MyISAM table could cause table corruption if the table had indexes. (Bug#40827)

mysqld_safe did not treat dashes and underscores as equivalent in option names. (Bug#40368)

If a transaction was implicitly committed by a START TRANSACTION or BEGIN statement, metadata locks held by the transaction incorrectly could be released before the commit actually occurred. (Bug#40188)

A multiple-table DELETE IGNORE statement involving a foreign key constraint caused an assertion failure. (Bug#40127)

Multiple-table UPDATE statements did not properly activate triggers. (Bug#39953)

The mysql_setpermission operation for removing database privileges removed global privileges instead. (Bug#39852)

A stored routine contain a C-style comment could not be dumped and reloaded. (Bug#39559)

In an UPDATE or DELETE via a secondary index, InnoDB did not store the cursor position. This made InnoDB crash in semi-consistent read while attempting to unlock a nonmatching record. (Bug#39320)

The functions listed in Section 11.13.4.2.3, “Creating Geometry Values Using MySQL-Specific Functions”, previously accepted WKB arguments and returned WKB values. They now accept WKB or geometry arguments and return geometry values.

The functions listed in Section 11.13.4.2.2, “Creating Geometry Values Using WKB Functions”, previously accepted WKB arguments and returned geometry values. They now accept WKB or geometry arguments and return geometry values. (Bug#38990)

On WIndows, running the server with myisam_use_mmap enabled caused MyISAM table corruption. (Bug#38848)

mysqlbinlog had a memory leak in its option-processing code. (Bug#38468)

Setting the general_log_file or slow_query_log_file system variable to a nonconstant expression caused the variable to become unset. (Bug#38124)

CHECK TABLE did not properly check whether MyISAM tables created by servers from MySQL 4.0 or older needed to be upgraded. This could cause problems upgrading to MySQL 5.1 or higher. (Bug#37631)

mysql_install_db failed if run as root and the root directory (/) was not writable. (Bug#36462)

An UPDATE statement that updated a column using the same DES_ENCRYPT() value for each row actually updated different rows with different values. (Bug#35087)

Inserting the result of CONCAT() invoked with a utf32 string and a number for arguments caused a server crash. (Bug#34021)

For shared-memory connections, the read and write methods did not properly handle asynchronous close events, which could lead to the client locking up waiting for a server response. For example, a call to mysql_real_query() would block forever on the client side if the executed statement was aborted on the server side. Thanks to Armin Schöffmann for the bug report and patch. (Bug#33899)

The default values for the general query log and slow query log file are documented to be based on the server host name and located in the data directory. However, they were in fact being based on the basename and location of the process ID (PID) file. The name and location defaults for the PID file are based on the server host name and data directory, so if it was not assigned a different name explicitly, its defaults were used and the general query log and slow query log file defaults were as documented. But if the PID file was assigned a value with the --pid-file option, the defaults for the general query log and slow query log file were incorrect. This has been rectified so that the defaults for all three files are based on the server host name and data directory.

A remaining problem is that the binary log and relay log .NNNNNN and .index basename defaults are based on the PID file basename, contrary to the documentation. This issue is to be addressed as Bug#45359. (Bug#33693)

The following statements generated an incorrect and confusing error message when used with ENGINE=MyISAM:

Such statements now fail with Error 1478, Table storage engine 'MyISAM' does not support the create option 'TABLESPACE or LOGFILE GROUP'. (Bug#31293)

myisamchk and myisampack were not being linked with the library that enabled support for * filename pattern expansion. (Bug#29248)

COMMIT did not delete savepoints if there were no changes in the transaction. (Bug#26288)

Several memory allocation functions were not being checked for out-of-memory return values. (Bug#25058)

Previously, the server handled character data types for a routine parameter, local routine variable created with DECLARE, or function return value as follows: If there was no CHARACTER SET attribute, the database character set and its default collation were used. If the CHARACTER SET attribute was present, the COLLATE attribute was not supported, so the character set's default collation was used. (This includes use of BINARY, because in this context BINARY specifies the binary collation of the character set.)

Now for character data types, if there is a CHARACTER SET attribute in the declaration, the specified character set and its default collation is used. If the COLLATE is also present, that collation is used rather than the default collation. If there is no CHARACTER SET attribute, the database character set and collation in effect at routine creation time are used. (The database character set and collation are given by the value of the character_set_database and collation_database system variables.) (Bug#24690)

Several data-modification statements were not being counted toward the MAX_UPDATES_PER_HOUR user resource limit. (Bug#21793)

Incompatible Change: The optimizer_switch system variable controls optimizations that can be switched on and off. The syntax for flags in its value has changed from 'no_opt_name' to 'opt_name={on|off|default}'. For information about the new syntax, see Section 7.2.22, “Using optimizer_switch to Control the Optimizer”.

Replication: The global server variables sync_master_info and sync_relay_log_info are introduced for use on replication slaves to control synchronization of, respectively, the master.info and relay.info files.

In each case, setting the variable to a nonzero integer value N causes the slave to synchonize the corresponding file to disk after every N events. Setting its value to 0 allows the operation system to handle syncronization of the file instead.

The actions of these variables, when enabled, are analogous to how the sync_binlog variable works with regard to binary logs on a replication master.

These variables can also be set in my.cnf, or by using the server options --sync-master-info and --sync-relay-log-info respectively.

An additional system variable relay_log_recovery is also now available. When enabled, this variable causes a replication slave to discard relay log files obtained from the replication master following a crash.

This variable can also be set in my.cnf, or by using the --relay-log-recovery server option.

This fix improves and expands upon one made in MySQL 6.0.10 which introduced the sync_relay_log variable. For more information about all of the server system variables introduced by these fixes, see Section 16.1.3.3, “Replication Slave Options and Variables”. (Bug#31665, Bug#35542, Bug#40337)

mysql-test-run.pl now supports an --experimental=file_name option. It enables you to specify a file that contains a list of test cases that should be displayed with the [ exp-fail ] code rather than [ fail ] if they fail. (Bug#42888)

The MD5 algorithm now uses the Xfree implementation. (Bug#42434)

The RESTORE statement now has a SKIP_GAP_EVENT option that causes the restore operation not to write the gap event to the binary log that causes any replication slaves to stop replication. This is useful when RESTORE is run on a master server and the backup image does not contain databases that are replicated to the slaves. (Bug#39780)

Previously, the --secure-file-priv option and secure_file_priv system variable, if set to a directory, limited BACKUP DATABASE and RESTORE operations to files in the given directory. Now the --secure-backup-file-priv option and secure_backup_file_priv system variable apply instead. (Bug#39581)

The query cache now checks whether a SELECT statement begins with SQL_NO_CACHE to determine whether it can skip checking for the query result in the query cache. This is not supported when SQL_NO_CACHE occurs within a comment. (Bug#37416)

A new program, mysqlbackup, displays information from backups created with the BACKUP DATABASE statement.

MySQL now implements the SQL standard SIGNAL and RESIGNAL statements. See Section 12.8.8, “SIGNAL and RESIGNAL”.

Incompatible Change: For system variables that take values of ON or OFF, OF was accepted as a legal variable. Now system variables that take “enumeration” values must be assigned the full value. This affects some other variables that previously could be assigned using unambiguous prefixes of allowable values, such as tx_isolation. (Bug#34828)

Incompatible Change: If a data definition language (DDL) statement occurred for a table that was being used by another session in an active transaction, statements could be written to the binary log in the wrong order. For example, this could happen if DROP TABLE occurred for a table being used in a transaction. This is now prevented by deferring release of metadata locks on tables used within a transaction until the transaction ends.

This bug fix results in some incompatibilities with previous versions:

(Bug#989)

Important Change: Replication: CHANGE MASTER TO ... MASTER_HOST='' — explicitly setting MASTER_HOST equal to an empty string — created a master.info file with an empty host field. This led to a The server is not configured as slave error when attempting to execute a START SLAVE statement. Now, if MASTER_HOST is set to an empty string, the CHANGE MASTER TO statement fails with an error. (Bug#28796)

Replication: Important Note: Binary logging with --binlog_format=ROW failed when a change to be logged included more than 251 columns. This issue was not known to occur with mixed-format or statement-based logging. (Bug#42977)

See also Bug#42914.

Replication: The SHOW SLAVE STATUS connection thread competed with the slave SQL thread for use of the error message buffer. As a result, the connection thread sometimes received incomplete messages. This issue was uncovered with valgrind when message strings were passed without NULL terminators, causing the error Conditional jump or move depends on uninitialised value(s). (Bug#43076)

Replication: This fix handles 2 issues encountered on replication slaves during startup:

(Bug#43075)

Replication: Assigning an invalid directory for the --slave-load-tmpdir caused the replication slave to crash. (Bug#42861)

Replication: The mysql.procs_priv system table was not replicated. (Bug#42217)

Replication: When --binlog_format was set to STATEMENT, a statement unsafe for statement-based logging caused an error or warning to be issued even if sql_log_bin was set to 0. (Bug#41980)

Replication: An INSERT DELAYED into a TIMESTAMP column issued concurrently with an insert on the same column not using DELAYED, but applied after the other insert, was logged using the same timestamp as generated by the other (non-DELAYED) insert. (Bug#41719)

Replication: When using MIXED replication format and temporary tables were created in statement-based mode, but a later operation in the same session caused a switch to row-based mode, the temporary tables were not dropped on the slave at the end of the session. (Bug#40013)

See also Bug#43046.

This regression was introduced by Bug#20499.

Replication: When using the MIXED replication format, UPDATE and DELETE statements that searched for rows where part of the key had nullable BIT columns failed. This occurred because operations that inserted the data were replicated as statements, but UPDATE and DELETE statements affecting the same data were replicated using row-based format.

This issue did not occur when using statement-based replication (only) or row-based replication (only). (Bug#39753)

See also Bug#39648.

Replication: The MIXED binary logging format did not switch to row-based mode for statements containing the LOAD_FILE() function. (Bug#39701)

Replication: The server SQL mode in effect when a stored procedure was created was not retained in the binary log. This could cause a CREATE PROCEDURE statement that succeeded on the master to fail on the slave.

This issue was first noticed when a stored procedure was created when ANSI_QUOTES was in effect on the master, but could possibly cause failed CREATE PROCEDURE statements and other problems on the slave when using other server SQL modes as well. (Bug#39526)

Replication: If --secure-file-priv was set on the slave, it was unable to execute LOAD DATA INFILE statements sent from the master when using mixed-format or statement-based replication.

As a result of this fix, this security restriction is now ignored on the slave in such cases; instead the slave checks whether the files were created and should be read by the slave in its --slave-load-tmpdir. (Bug#38174)

Replication: When using row-based format, replication failed with the error Could not execute Write_rows event on table ...; Field '...' doesn't have a default value when an INSERT was made on the master without specifying a value for a column having no default, even if strict server SQL mode was not in use and the statement would otherwise have succeeded on the master. Now the SQL mode is checked, and the statement is replicated unless strict mode is in effect. For more information, see Section 5.1.8, “Server SQL Modes”. (Bug#38173)

See also Bug#38262, Bug#43992.

Replication: Server IDs greater than 2147483647 (2³² – 1) were represented by negative numbers in the binary log. (Bug#37313)

Replication: The value of Slave_IO_running in the output of SHOW SLAVE STATUS did not distinguish between all 3 possible states of the slave I/O thread (not running; running but not connected; connected). Now the value Connecting (rather than No) is shown when the slave I/O thread is running but the slave is not connected to a replication master.

The server system variable Slave_running also reflects this change, and is now consistent with what is shown for Slave_IO_running. (Bug#30703, Bug#41613)

Replication: Queries which were written to the slow query log on the master were not written to the slow query log on the slave. (Bug#23300)

Replication: When the server SQL mode included IGNORE_SPACE, statement-based replication of LOAD DATA INFILE ... INTO tbl_name failed because the statement was read incorrectly from the binary log; a trailing space was omitted, causing the statement to fail with a syntax error when run on the slave. (Bug#22504)

See also Bug#43746.

Replication: When its disk becomes full, a replication slave may wait while writing the binary log, relay log or MyISAM tables, continuing after space has been made available. The error message provided in such cases was not clear about the frequency with which checking for free space is done (once every 60 seconds), and how long the server waits after space has been freed before continuing (also 60 seconds); this caused users to think that the server had hung.

These issues have been addressed by making the error message clearer, and dividing it into two separate messages:

(Bug#22082)

Memory corruption of join buffers could occur when using the Batched Key Access algorithm with incremental join buffers to execute join operations for a query over several tables that selects BLOB values. (Bug#44250)

The server could crash at startup when initializing plugins listed in the plugin table. (Bug#44137)

A RESTORE operation that restored a MyISAM table using the native MyISAM restore driver could cause the MyISAM key cache to be disabled. (Bug#44068)

In some cases, when the Batched Key Access algorithm is used with join_cache_level equal to 6, multi-join queries could return incorrect results. (Bug#44019)

valgrind would report errors for the StorageInterface, StorageHAndler and CmdGen portions of Falcon. (Bug#43995)

On 64-bit debug builds, code in safemalloc resulted in errors due to use of a 32-bit value for 64-bit allocations. (Bug#43885)

When performing a high number of concurrent index updates on a Falcon table, mysqld could crash due to an assertion. (Bug#43765)

An attempt by a user who did not have the SUPER privilege to kill a system thread could cause a server crash. (Bug#43748)

On Windows, incorrectly specified link dependencies in CMakeLists.txt resulted in link errors for mysql_embedded, mysqltest_embedded, and mysql_client_test_embedded. (Bug#43715)

make distcheck failed to properly handle subdirectories of storage/ndb. (Bug#43614)

Incorrect use of parser information could lead to acquisition of incorrect lock types. (Bug#43568)

Upgrading MySQL to 6.0.10 from 6.0.9 when using Falcon tables and the mysql_upgrade tool would cause mysqld to crash during start up. (Bug#43562)

Running a SELECT using a range query on FLOAT on a Maria table could return invalid result sets. (Bug#43552)

Running a SELECT using a range query on with <> or < with a negative values on a Maria table could return invalid result sets. (Bug#43530)

Running a SELECT on a multi-range query with a LIMIT clause on a Maria table could return invalid result sets. (Bug#43527)

Executing a LIMIT ... FOR UPDATE statement on a Falcon table when using transactions with concurrent threads could cause a crash because the record information cannot be accessed correctly. (Bug#43488)

When performing SELECT statements on a Falcon table using an indexed INTEGER column could return incorrect row matches. (Bug#43452)

RESTORE on a case-insensitive server failed if the backup image contained databases or tables with uppercase names. Now, RESTORE handles this case by converting the names to lowercase in the restore catalog, as long as there are no duplicate names after the conversion. (Bug#43363)

Use of USE INDEX hints could cause EXPLAIN EXTENDED to crash. (Bug#43354)

BACKUP DATABASE stored incorrect table counts in the backup image. (Bug#43324)

Assigning a value to the backupdir system variable resulted in Valgrind errors. (Bug#43303)

mysql crashed if a request for the current database name returned an empty result, such as after the client has executed a preceding SET sql_select_limit=0 statement. (Bug#43254)

If the value of the version_comment system variable was too long, the mysql client displayed a truncated startup message. (Bug#43153)

Compilation failures on Windows Vista using Visual Studio 2008 Professional were corrected. (Bug#43120)

Recovering a Falcon table from a failure when the table contains BLOB columns could cause an assertion failure. (Bug#43106)

On 32-bit Windows, mysqld could not use large buffers due to a 2GB user mode address limit. (Bug#43082)

mysqld would crash when using Falcon tables during shutdown if the server was running in embedded mode. (Bug#43048)

The MySQL Backup library had incorrect logic and error reporting for metadata saving. (Bug#42959)

Queries of the following form returned an empty result:

SELECT ... WHERE ... (col=col AND col=col) OR ... (false expression)

(Bug#42957)

A two-way join query with a GROUP BY or ORDER BY clause could produce incorrect results when rows of the first table are accessed by an index compatible with the GROUP BY or ORDER BY list while the second table is joined using the Batched Key Access algorithm. (Bug#42955)

The strings/CHARSET_INFO.txt file was not included in source distributions. (Bug#42937)

When running REPAIR on a crashed Falcon table can crash mysqld if pages have been incorrectly marked dirty, but not locked, during write. (Bug#42824)

stderr should be unbuffered, but when the server redirected stderr to a file, it became buffered. (Bug#42790)

The DATA_TYPE column of the INFORMATION_SCHEMA.COLUMNS table displayed the UNSIGNED attribute for floating-point data types. (The column should contain only the data type name.) (Bug#42758)

Recovery of Falcon tables while there were active transaction during the crash may fail to recover completely. (Bug#42743)

Use of semijoin optimization could cause a server crash. (Bug#42740)

When Falcon is populating the INFORMATION_SCHEMA.TABLESPACES table, an exception can be raised because required result set has been closed before the resultset has been completed. This can happen during a BACKUP operation. (Bug#42725, Bug#42830)

Assigning a value to the backupdir system variable resulted in a memory leak. (Bug#42695)

Assigning an incorrect value to the backup_progress_log_file system variable resulted in Valgrind errors. (Bug#42685)

When performing SELECT queries on tables containing TIMESTAMP or DATETIME colums with indexes using a WHERE clause comparing the field value to NULL using the <= or <> operators, the wrong information would be returned. (Bug#42683, Bug#43623, Bug#43620, Bug#42681)

A dangling pointer in mysys/my_error.c could lead to client crashes. (Bug#42675)

mysqldump included views that were excluded with the --ignore-table option. (Bug#42635)

An earlier bug fix resulted in the problem that the InnoDB plugin could not be used with a server that was compiled with the built-in InnoDB. To handle this two changes were made:

(Bug#42610)

This regression was introduced by Bug#29263.

With the ONLY_FULL_GROUP_BY SQL mode enabled, some legal queries failed. (Bug#42567)

Recovery of a Falcon table with a large number of rows can cause a failure in the page type written for the internal FALCON_USER and FALCON_TEMPORARY tablespaces. (Bug#42560)

Passing an unknown time zone specification to CONVERT_TZ() resulted in a memory leak. (Bug#42502)

Tables could enter open table cache for a thread without being properly cleaned up, leading to a server crash. (Bug#42419)

Previously, RESTORE would crash if the backup image contained tables originally stored in a tablespace that no longer existed at RESTORE time. Now the tablespace is recreated like it was at BACKUP DATABASE time if it does not exist when RESTORE is executed. (Bug#42402)

If the server was started with --thread_handling=pool-of-threads, the MAX_QUERIES_PER_HOUR user resource limit. (Bug#42384)

Recovery of Falcon tables with indexes can fail because the index page information has not been recorded properly. (Bug#42344)

Using a LIKE clause on a Maria table using an index and the CP1251 collation would return invalid data. (Bug#42299)

Running a SELECT using a JOIN on a Maria table could return invalid result sets. (Bug#42298)

Running multi-range queries on Maria tables could cause a crash. (Bug#42297)

Using a falcon-scavenge-schedule of * * * * * would cause Falcon to never execute the required threads to operate. (Bug#42275)

If the server was started with an option that had a missing or invalid value, a subsequent error that would cause normally the server to shut down could cause it to crash instead. (Bug#42244)

Using ORDER BY and or LIMIT on Falcon tables could give inconsistent results for rows that contain NULL columns in the corresponding ORDER BY clause. (Bug#42208)

For InnoDB tables, there was a race condition for ALTER TABLE, OPTIMIZE TABLE, CREATE INDEX, and DROP INDEX operations when periodically checking whether table copying can be committed. (Bug#42152)

In InnoDB recovery after a server crash, table lookup could fail and corrupt the data dictionary cache. (Bug#42075)

mysqldumpslow parsed the --debug and --verbose options incorrectly. (Bug#42027)

BACKUP DATABASE and RESTORE did not implement backup and restore of privileges for stored procedures and stored functions. (Bug#41979)

Recovering a Falcon table that uses BLOB columns could cause unbounded tablespace growth before recovery completes. (Bug#41840)

Recovery of Falcon tables could fail with an indicating that a wrong page type was identified in the Falcon serial log. (Bug#41837, Bug#42745, Bug#44114)

RESTORE crashed for Falcon tables. (Bug#41722)

With more than two arguments, LEAST(), GREATEST(), and CASE could unnecessarily return Illegal mix of collations errors. (Bug#41627)

Queries that used the loose index scan access method could return no rows. (Bug#41610)

RESTORE failed if it tried to restore a privilege for a nonexistent object. (Bug#41578)

In InnoDB recovery after a server crash, rollback of a transaction that updated a column from NULL to NULL could cause another crash. (Bug#41571)

The mysql client could misinterpret its input if a line was longer than an internal buffer. (Bug#41486)

The error message for a too-long column comment was Unknown error rather than a more appropriate message. (Bug#41465)

The Falcon CycleManager has been updated, which addresses a number of issues when examining records in various transaction states and their visisbility/isolation in relation to other threads. (Bug#41391, Bug#41478, Bug#41742, Bug#41850, Bug#42459, Bug#41661, Bug#42185, Bug#43146, Bug#43298, Bug#43299, Bug#34624, Bug#42189)

Use of SELECT * allowed users with rights to only some columns of a view to access all columns. (Bug#41354)

If the tables underlying a MERGE table had a primary key but the MERGE table itself did not, inserting a duplicate row into the MERGE table caused a server crash. (Bug#41305)

In the help command output displayed by mysql, the description for the \c (clear) command was misleading. (Bug#41268)

Several resource leaks were corrected in the error-handling code for the MySQL Backup library. (Bug#41250, Bug#41294)

The server did not robustly handle problems hang if a table opened with HANDLER needed to be re-opened because it had been altered to use a different storage engine that does not support HANDLER. The server also failed to set an error if the re-open attempt failed. These problems could cause the server to crash or hang. (Bug#41110, Bug#41112)

SELECT statements executed concurrently with INSERT statements for a MyISAM table could cause incorrect results to be returned from the query cache. (Bug#41098)

For prepared statements, multibyte character sets were not taking into account when calculating max_length for string values and mysql_stmt_fetch() could return truncated strings. (Bug#41078)

For user-defined variables in a query result, incorrect length values were returned in the result metadata. (Bug#41030)

Using RESTORE to restore a database through a named pipe resulted in corrupt data. (Bug#40975)

Performing SELECT operations on Falcon tables using the maximum BIG INT value would fail to return matching rows. (Bug#40950)

For some queries, an equality propagation problem could cause a = b and b = a to be handled differently. (Bug#40925)

With strict SQL mode enabled, setting a system variable to an out-of-bounds value caused an assertion failure. (Bug#40657)

Table temporary scans were slower than necessary due to use of mmap rather than caching, even with the myisam_use_mmap system variable disabled. (Bug#40634)

Indexes on Falcon tables using numeric columns could return incorrect information. (Bug#40607, Bug#41582, Bug#40950)

The load_defaults(), my_search_option_files() and my_print_default_files() functions in the C client library were subject to a race condition in multi-threaded operation. (Bug#40552)

For a view that references a table in another database, mysqldump wrote the view name qualified with the current database name. This makes it impossible to reload the dump file into a different database. (Bug#40345)

On platforms where long and pointer variables have different sizes, MyISAM could copy key statistics incorrectly, resulting in a server crash or incorrect cardinality values. (Bug#40321)

Falcon could cause an assertion when the system has run out of memory and tries to report the memory allocation failure. (Bug#40155)

DELETE tried to acquire write (not read) locks for tables accessed within a subquery of the WHERE clause. (Bug#39843)

mysql_upgrade did not remove the online_backup and online_backup_progress tables from the mysql database. (These are what the backup_history and backup_progress tables were called previously.) (Bug#39655)

With row-based binary logging, replication of InnoDB tables containing NULL-valued BIT columns could fail. (Bug#39648)

When using Falcon and the system runs out of all memory and swap space, mysqld could hang while attempting to write an error message. (Bug#39552)

The mysql_stmt_close() C API function did not flush all pending data associated with the prepared statement. (Bug#39519)

Updating Falcon tables after an online ALTER ADD COLUMN operation could fail. (Bug#39445)

Following ALTER TABLE ... DISCARD TABLESPACE for an InnoDB table, an attempt to determine the free space for the table before the ALTER TABLE operation had completely finished could cause a server crash. (Bug#39438)

perror did not produce correct output for error codes 153 to 163. (Bug#39370)

If --basedir was specified, mysqld_safe did not use it when attempting to locate my_print_defaults. (Bug#39326)

Several functions in libmysqld called exit() when an error occurred rather than returning an error to the caller. (Bug#39289)

Performing an online ALTER TABLE statement against a Falcon table, the Falcon serial log could grow beyond the maximum permitted size for a serial log, ignoring both the rotation and truncation. (Bug#39130)

Previously, the num_objects column in the backup_history table showed only the number of tables in the backup image. It now shows the number of objects with names (tablespaces, databases, tables, views, stored programs). (Bug#39109)

BACKUP DATABASE treated the database list in case-sensitive fashion, even on case-insensitive file systems. (Bug#39063)

The ALTER ROUTINE privilege incorrectly allowed SHOW CREATE TABLE. (Bug#38347)

BACKUP DATABASE crashed if there was no default database. (Bug#38294)

Setting a savepoint with the same name as an existing savepoint incorrectly deleted any other savepoints that had been set in the meantime. For example, setting savepoints named a, b, c, b resulted in savepoints a, b, rather than the correct savepoints a, c, b. (Bug#38187)

Locking of myisam.log did not work correctly on Windows. (Bug#38133, Bug#41224)

--help output for myisamchk did not list the --HELP option. (Bug#38103)

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

Comparisons between row constructors, such as (a, b) = (c, d) resulted in unnecessary Illegal mix of collations errors for string columns. (Bug#37601)

A workload consisting of CREATE TABLE ... SELECT and DML operations could cause deadlock. (Bug#37433)

If a user created a view that referenced tables for which the user had disjoint privileges, an assertion failure occurred. (Bug#37191)

Trying to recover Falcon tables after a crash when the corresponding tables and tablespaces have not been created before the crash could cause a recovery failure. (Bug#36993)

When MySQL was configured with the --with-max-indexes=128 option, mysqld crashed. (Bug#36751)

The event, general_log, and slow_log tables in the mysql database store server_id values, but did not use an UNSIGNED column and thus were not able to store the full range of ID values. (Bug#36540)

Setting the join_buffer_size variable to its minimum value produced spurious warnings. (Bug#36446)

The audit plugin was not receiving MYSQL_AUDIT_GENERAL_ERROR events. (Bug#36098)

The use of NAME_CONST() can result in a problem for CREATE TABLE ... SELECT statements when the source column expressions refer to local variables. Converting these references to NAME_CONST() expressions can result in column names that are different on the master and slave servers, or names that are too long to be legal column identifiers. A workaround is to supply aliases for columns that refer to local variables.

Now a warning is issued in such cases that indicate possible problems. (Bug#35383)

SHOW CREATE EVENT output did not include the DEFINER clause. (Bug#35297)

mysqld would crash in a concurrent workload with INSERT/CREATE TABLE/DROP TABLE or INSERT/ALTER TABLE combinations on Falcon tables. (Bug#35255)

It was not possible to interrupt a long running BACKUP DATABASE or RESTORE operation. (Bug#35079)

Several deprecated or obsolete settings were removed from the sample option files. (Bug#34521)

Searching for 0x00 in Falcon tables using the VARBINARY column type would fail to return the correct rows. In addition, a crash could be encountered when modifying a column to the VARBINARY type. (Bug#34478, Bug#33190, Bug#23692)

A subquery using SELECT ... FOR UPDATE on a Falcon table fails to lock table correctly during the UPDATE. (Bug#34182)

With Falcon tables running concurrent transactions, some transactions may not be rolled back correctly, leading to an infinite loop. (Bug#34174)

INSTALL PLUGIN and UNINSTALL PLUGIN did not handle plugin identifiers consistently with respect to lettercase. (Bug#33731)

RESTORE often would not correctly identify the tablespace into which a Falcon table should be restored. (Bug#33569)

mysqldump --compatible=mysql40 emitted statements referring to the character_set_client system variable, which is unknown before MySQL 4.1. Now the statements are enclosed in version-specific comments. (Bug#33550)

If Falcon runs out of memory while inserting records and you try to alter the affected table, you may get a record memory is exhausted error, and the table can no longer be used or accessed. (Bug#33177)

The DDL blocker for BACKUP DATABASE and RESTORE did not block all statements that it should. The blocker is now called the Backup Metadata Lock and blocks statements that change database metadata. (Bug#32702)

Detection by configure of several functions such as setsockopt(), bind(), sched_yield(), and gtty() could fail. (Bug#31506)

Use of MBR spatial functions such as MBRTouches() with columns of InnoDB tables caused a server crash rather than an error. (Bug#31435)

When an InnoDB tablespace filled up, an error was logged to the client, but not to the error log. Also, the error message was misleading and did not indicate the real source of the problem. (Bug#31183)

The mysql client mishandled input parsing if a delimiter command was not first on the line. (Bug#31060)

SHOW PRIVILEGES listed the CREATE ROUTINE privilege as having a context of Functions,Procedures, but it is a database-level privilege. (Bug#30305)

CHECK TABLE, REPAIR TABLE, ANALYZE TABLE, and OPTIMIZE TABLE erroneously reported a table to be corrupt if the table did not exist or the statement was terminated with KILL. (Bug#29458)

For InnoDB tables that have their own .ibd tablespace file, a superfluous ibuf cursor restoration fails! message could be written to the error log. This warning has been suppressed. (Bug#27276)

Internal base64_xxx() functions were renamed to have a prefix of my_ to avoid conflicts with other libraries. (Bug#26818)

The Time column for SHOW PROCESSLIST output and the value of the TIME column of the INFORMATION_SCHEMA.PROCESSLIST table now can have negative values. Previously, the column was unsigned and negative values were displayed incorrectly as large positive values. Negative values can occur if a thread alters the time into the future with SET TIMESTAMP = value or the thread is executing on a slave and processing events from a master that has its clock set ahead of the slave. (Bug#22047)

Restoring a mysqldump dump file containing FEDERATED tables failed because the file contained the data for the table. Now only the table definition is dumped (because the data is located elsewhere). (Bug#21360)

SHOW CREATE DATABASE did not account for the value of the lower_case_table_names system variable. (Bug#21317)

Incorrect length metadata could be returned for LONG TEXT columns when a multibyte server character set was used. (Bug#19829)

ROUND() sometimes returned different results on different platforms. (Bug#15936)

Important Change: Replication: RESET MASTER and RESET SLAVE now reset the values shown for Last_IO_Error, Last_IO_Errno, Last_SQL_Error, and Last_SQL_Errno in the output of SHOW SLAVE STATUS. (Bug#34654)

Replication: A new global server variable sync_relay_log is introduced for use on replication slaves. Setting this variable to a nonzero integer value N causes the slave to synchonize the relay log to disk after every N events. Setting its value to 0 allows the operation system to handle syncronization of the file. The action of this variable, when enabled, is analogous to how the sync_binlog variable works with regard to binary logs on a replication master.

This variable can also be set in my.cnf, or by using the server option --sync-relay-log.

For more information, see Section 16.1.3.3, “Replication Slave Options and Variables”. (Bug#31665, Bug#35542, Bug#40337)

Replication: In circular replication, it was sometimes possible for an event to propagate such that it would be reapplied on all servers. This could occur when the originating server was removed from the replication circle and so could no longer act as the terminator of its own events, as normally happens in circular replication.

In order to prevent this from occurring, a new IGNORE_SERVER_IDS option is introduced for the CHANGE MASTER TO statement. This option takes a list of replication server IDs; events having a server ID which appears in this list are ignored and not applied. For more information, see Section 12.6.2.1, “CHANGE MASTER TO Syntax”. (Bug#25998)

See also Bug#27808.

The libedit library was upgraded to version 2.11. (Bug#42433)

A new status variable, Queries, indicates the number of statements executed by the server. This includes statements executed within stored programs, unlike the Questions variable which includes only statements sent to the server by clients. (Bug#41131)

Columns that provide a catalog value in INFORMATION_SCHEMA tables (for example, TABLES.TABLE_CATALOG) now have a value of def rather than NULL. (Bug#35427)

mysql-test-run.pl now supports --client-bindir and --client-libdir options for specifying the directory where client binaries and libraries are located. (Bug#34995)

Security Fix: Using an XPath expression employing a scalar expression as a FilterExpr with ExtractValue() or UpdateXML() caused the server to crash. Such expressions now cause an error instead. (Bug#42495)

Incompatible Change: The fix for Bug#33699 introduced a change to the UPDATE statement such that assigning NULL to a NOT NULL column caused an error even when strict SQL mode was not enabled. The original behavior before was that such assignments caused an error only in strict SQL mode, and otherwise set the column to the implicit default value for the column data type and generated a warning. (For information about implicit default values, see Section 10.1.4, “Data Type Default Values”.)

The change caused compatibility problems for applications that relied on the original behavior. It also caused replication problems between servers that had the original behavior and those that did not, for applications that assigned NULL to NOT NULL columns in UPDATE statements without strict SQL mode enabled. This change has been reverted so that UPDATE again had the original behavior. Problems can still occur if you replicate between servers that have the modified UPDATE behavior and those that do not. (Bug#39265)

Incompatible Change: Falcon supported case-sensitive tablespace names. The code has been changed so that all tablespace names are converted to uppercase names during creation. Because of this change:

(Bug#35257, Bug#33719)

Important Change: Replication: If a trigger was defined on an InnoDB table and this trigger updated a nontransactional table, changes performed on the InnoDB table were replicated and were visible on the slave before they were committed on the master, and were not rolled back on the slave after a successful rollback of those changes on the master.

As a result of the fix for this issue, the semantics of mixing nontransactional and transactional tables in a transaction in the first statement of a transaction have changed. Previously, if the first statement in a transaction contained nontransactional changes, the statement was written directly to the binary log. Now, any statement appearing after a BEGIN (or immediately following a COMMIT if AUTOCOMMIT = 0) is always considered part of the transaction and cached. This means that nontransactional changes do not propagate to the slave until the transaction is committed and thus written to the binary log.

See Section 16.3.1.25, “Replication and Transactions”, for more information about this change in behavior. (Bug#40116)

Important Change: Replication: MyISAM transactions replicated to a transactional slave left the slave in an unstable condition. This was due to the fact that, when replicating from a nontransactional storage engine to a transactional engine with AUTOCOMMIT turned off, no BEGIN and COMMIT statements were written to the binary log; thus, on the slave, a never-ending transaction was started.

The fix for this issue includes enforcing AUTOCOMMIT mode on the slave by replicating all AUTOCOMMIT=1 statements from the master. (Bug#29288)

Partitioning: A comparison with an invalid DATE value in a query against a partitioned table could lead to a crash of the MySQL server.

(Bug#40972)

Partitioning: A query that timed out when run against a partitioned table failed silently, without providing any warnings or errors, rather than returning Lock wait timeout exceeded. (Bug#40515)

Partitioning: ALTER TABLE ... REORGANIZE PARTITION could crash the server when the number of partitions was not changed. (Bug#40389)

See also Bug#41945.

Partitioning: ALTER TABLE ... ADD PARTITION and ALTER TABLE ... DROP PARTITION could cause the MySQL server to crash. This was only known to occur on Windows platforms where MySQL had been built with the EXTRA_DEBUG option. (Bug#38784)

Partitioning: SHOW TABLE STATUS could show a nonzero value for the Mean record length of a partitioned InnoDB table, even if the table contained no rows. (Bug#36312)

Partitioning: Several error messages relating to partitioned tables were incorrect or missing. (Bug#36001)

Partitioning: Unnecessary calls were made in the server code for performing bulk inserts on partitions for which no inserts needed to be made. (Bug#35845)

See also Bug#35843.

Partitioning: For partitioned tables with more than ten partitions, a full table scan was used in some cases when only a subset of the partitions were needed. (Bug#33730)

Replication: On Windows, RESET MASTER failed in the event of a missing binlog file rather than issuing a warning and completing the rest of the statement. (Bug#42150, Bug#42288)

Replication: Per-table AUTO_INCREMENT option values were not replicated correctly for InnoDB tables. (Bug#41986)

Replication: Some log_event types did not skip the post-header when reading. (Bug#41961)

Replication: Attempting to read a binary log containing an Incident_log_event having an invalid incident number could cause the debug server to crash. (Bug#40482)

Replication: When CHANGE MASTER TO ... SET MASTER_HEARTBEAT_PERIOD ... failed, no error code was set. (Bug#40459)

Replication: When using row-based replication, an update of a primary key that was rolled back on the master due to a duplicate key error was not rolled back on the slave. (Bug#40221)

Replication: When rotating relay log files, the slave deletes relay log files and then edits the relay log index file. Formerly, if the slave shut down unexpectedly between these two events, the relay log index file could then reference relay logs that no longer existed. Depending on the circumstances, this could when restarting the slave cause either a race condition or the failure of replication. (Bug#38826, Bug#39325)

Replication: START SLAVE UNTIL did not work correctly with --replicate-same-server-id enabled; when started with this option, the slave did not perform events recorded in the relay log and that originated from a different master.

Log rotation events are automatically generated and written when rotating the binary log or relay log. Such events for relay logs are usually ignored by the slave SQL thread because they have the same server ID as that of the slave. However, when --replicate-same-server-id was enabled, the rotation event for the relay log was treated as if it originated on the master, because the log's name and position were incorrectly updated. This caused the MASTER_POS_WAIT() function always to return NULL and thus to fail. (Bug#38734, Bug#38934)

Replication: A slave compiled using --with-libevent and run with --thread-handling=pool-of-threads could sometimes crash. (Bug#36929)

Replication: TRUNCATE statements failed to replicate when statement-based binary logging mode was not available. The issue was observed when using InnoDB with the transaction isolation level set to READ UNCOMMITTED (thus forcing InnoDB not to allow statement-based logging). However, the same behavior could be reproduced using any transactional storage engine supporting only row-based logging, regardless of the isolation level. This was due to two separate problems:

As a result of this fix, TRUNCATE is now treated as DDL for purposes of binary logging and replication; that is, it is always logged as a statement and so no longer causes an error when replicated using a transactional storage engine such as InnoDB. (Bug#36763)

See also Bug#42643.

Replication: mysqlbinlog replay of CREATE TEMPORARY TABLE ... LIKE statements and of TRUNCATE statements used on temporary tables failed with Error 1146 (Table ... doesn't exist). (Bug#35583)

Replication: mysqlbinlog sometimes failed when trying to create temporary files; this was because it ignored the specified temp file directory and tried to use the system /tmp directory instead. (Bug#35546)

See also Bug#35543.

Replication: In statement mode, mysqlbinlog failed to issue a SET @@autommit statement when the autocommit mode was changed. (Bug#34541)

Replication: LOAD DATA INFILE statements did not replicate correctly from a master running MySQL 4.1 to a slave running MySQL 5.1 or later. (Bug#31240)

Replication: The statements DROP PROCEDURE IF EXISTS and DROP FUNCTION IF EXISTS were not written to the binary log if the procedure or function to be dropped did not exist. (Bug#13684)

See also Bug#25705.

The optimizer could underestimate the memory required for column descriptors during join processing and cause memory corruption or a server crash. (Bug#42744)

A '%' character in SQL statements could cause the server to crash. (Bug#42634)

For the batched-key access method, numbers of records were being specified rather than numbers of ranges. (Bug#42593)

Certain queries could result in Valgrind warnings in the optimizer. (Bug#42534)

An optimization introduced for Bug#37553 required an explicit cast to be added for some uses of TIMEDIFF() because automatic casting could produce incorrect results. (It was necessary to use TIME(TIMEDIFF(...)).) (Bug#42525)

On the IBM i5 platform, the MySQL configuration process caused the system version of pthread_setschedprio() to be used. This function returns SIGILL on i5 because it is not supported, causing the server to crash. Now the my_pthread_setprio() function in the mysys library is used instead. (Bug#42524)

Performing a BACKUP and RESTORE on a Maria table while an existing workload is in progress could lead to a corrupted table and possible crash. (Bug#42519)

The default Falcon memory parameters have been updated, which should help to improve performance. The new settings for all the memory parameters are as follows:

(Bug#42510, Bug#36442)

When running Falcon during a very high concurrency workload, mysqld could fail. (Bug#42475)

Falcon would fail to create a table in a TABLESPACE that had not already been opened by a previous operation. (Bug#42414, Bug#42743)

The recovery of Falcon tablespaces could fail because the tablespace information had become corrupt. (Bug#42392)

The SSL certficates included with MySQL distributions were regenerated because the previous ones had expired. (Bug#42366)

A deadlocked Maria table would incorrectly be marked as crashed. (Bug#42201)

INSERT operations to a Falcon table involving BIT columns with an index would fail to find the correct rows to update. (Bug#42196)

User variables within triggers could cause a crash if the mysql_change_user() C API function was invoked. (Bug#42188)

Parsing of the optional microsecond component of DATETIME values did not fail gracefully when that component width was larger than the allowed six places. (Bug#42146)

For Falcon tables, range queries using an index prefix were slow when Multi-Range Read index scans were disabled. (Bug#42136, Bug#41890)

The ALTER ONLINE TABLE statement for Falcon tables would not include support for add a primary key. (Bug#42099)

Sequences and auto increment values in Falcon tables would not reset, even when a TRUNCATE TABLE operation was executed. The behavior has now been updated to reset the values to the original table definition when TRUNCATE TABLE is applied. (Bug#42079)

Dependent subqueries such as the following caused a memory leak proportional to the number of outer rows:

SELECT COUNT(*) FROM t1, t2 WHERE t2.b
  IN (SELECT DISTINCT t2.b FROM t2 WHERE t2.b = t1.a);

(Bug#42037)

Queries executed using a join buffer could return incorrect results. (Bug#42020)

Some queries using NAME_CONST(.. COLLATE ...) led to a server crash due to a failed type cast. (Bug#42014)

The MAP file was not included in Windows distribution, but is needed by the InnoDB plugin. MAP file generation has again been enabled. (Bug#42001)

The optimizer underestimated the number of field descriptors for the join buffer in some cases. (Bug#41919)

Internal misconfiguration of the hash table used for the join buffer could cause a server crash. (Bug#41894)

String reallocation could cause memory overruns. (Bug#41868)

Queries executed using semi-join materialization could cause a crash if the outer query has a HAVING clause. (Bug#41842)

Running concurrent nontransactional queries on a Falcon table could cause a crash. (Bug#41835)

mysql_install_db did not pass some relevant options to mysqld. (Bug#41828)

A Valgrind warning in open_tables() was corrected. (Bug#41759)

A Valgrind warning in setup_wild() was corrected. (Bug#41729)

For Falcon tables, concurrent execution of a statement which in the general case should acquire a TL_READ_NO_INSERT lock on the table (for example multiple-table update, DML with subqueries, or statements involving new foreign key checks) and a statement that modifies the table might lead to warnings in the error log or even to deadlocks. (Bug#41688, Bug#42069)

Setting innodb_locks_unsafe_for_binlog should be equivalent to setting the transaction isolation level to READ COMMITTED. However, if both of those things were done, nonmatching semi-consistently read rows were not unlocked when they should have been. (Bug#41671)

resolve_stack_dump was unable to resolve the stack trace format produced by mysqld in MySQL 5.1 and up (see Section 21.5.1.5, “Using a Stack Trace”). (Bug#41612)

In example option files provided in MySQL distributions, the thread_stack value was increased from 64K to 128K. (Bug#41577)

REPAIR TABLE crashed for compressed MyISAM tables. (Bug#41574)

The ALTER TABLESPACE statement would fail on Falcon tablespaces because of incorrect assumption about TABLESPACE support for the Falcon engine. (Bug#41548)

When opening a Falcon TABLESPACE, the server could crash if the tablespace header could not be read correctly, including if the tablespace had become corrupt or deleted. Now an error will be thrown and reported to the error log. (Bug#41545)

The optimizer could ignore an error and rollback request during a filesort, causing an assertion failure. (Bug#41543)

Recovery of Maria tables with BLOB columns could fail to complete correctly. (Bug#41493)

DATE_FORMAT() could cause a server crash for year-zero dates. (Bug#41470)

BACKUP DATABASE and RESTORE did not reset the message list displayed by SHOW WARNINGS. (Bug#41468, Bug#41359)

SET PASSWORD caused a server crash if the account name was given as CURRENT_USER(). (Bug#41456)

When substituting system constant functions with a constant result, the server was not expecting NULL function return values and could crash. (Bug#41437)

The mysql-test/include/UnicodeData.txt file, if present, was not included in MySQL distributions. (Bug#41436)

When using TRUNCATE on a Falcon table, the sequence value for auto increment columns would not be reset correctly. (Bug#41411)

For a TIMESTAMP NOT NULL DEFAULT ... column, storing NULL as the return value from some functions caused a “cannot be NULL” error. NULL returns now correctly cause the column default value to be stored. (Bug#41370)

Queries such as SELECT ... CASE AVG(...) WHEN ... that used aggregate functions in a CASE expression crashed the server. (Bug#41363)

INSERT INTO .. SELECT ... FROM and CREATE TABLE ... SELECT ... FROM a TEMPORARY table could inadvertently change the locking type of the temporary table from a write lock to a read lock, causing statement failure. (Bug#41348)

Recovery of Falcon tables after a crash if falcon_page_size had been set to 32K and BLOB columns were used in the Falcon tables. (Bug#41227)

On Windows, the server could not be started with the --thread-handling=pool-of-threads option. (Bug#41218)

Transactions in Falcon tables could be recorded incorrectly, leading other waiting transactions to complete even though the original transaction information had not been successfully made durable. (Bug#41194)

For a query that is executed using a range access method over an index that matches the ordering and there is an ORDER BY clause, EXPLAIN showed Using MRR even though Multi-Range Read access was not used. (Bug#41136)

The server cannot execute INSERT DELAYED statements when statement-based binary logging is enabled, but the error message displayed only the table name, not the entire statement. (Bug#41121)

FULLTEXT indexes did not work for Unicode columns that used a custom UCA collation. (Bug#41084)

The INFORMATION_SCHEMA.SCHEMA_PRIVILEGES table was limited to 7680 rows. (Bug#41079)

In debug builds, obsolete debug code could be used to crash the server. (Bug#41041)

When a storage engine plugin failed to initialize before allocating a slot number, it would acidentally unplug the engine in slot 0. (Bug#41013)

Some queries that used a “range checked for each record” scan could return incorrect results. (Bug#40974)

For BACKUP DATABASE, errors from the commit blocker were not logged. (Bug#40970)

Certain SELECT queries could fail with a Duplicate entry error. (Bug#40953)

For debug servers, OPTIMIZE TABLE on a compressed table caused a server crash. (Bug#40949)

The Windows installer displayed incorrect product names in some images. (Bug#40845)

The CSV engine did not parse '\X' characters when they occurred in unquoted fields. (Bug#40814)

Comparison of empty strings for the latin2_czech_cs character set could hang. (Bug#40805)

The Falcon storage engine has been updated to incorporate new code for the built-in scavenger service, which handles the caching of records in memory. This fixes a number of different issues related to the visibility of different records during certain operations and improves the memory usage. The same fix also corrects the behavior where the space allocated for BLOB records would not be recovered correctly, causing the size of the Falcon table space files to increase with each BLOB INSERT or UPDATE operation. (Bug#40801, Bug#34893, Bug#36700, Bug#40342, Bug#41831, Bug#41870)

IF(..., CAST(longtext_val AS UNSIGNED), signed_val) as an argument to an aggregate function could cause an assertion failure. (Bug#40761)

Changing innodb_thread_concurrency at runtime could cause errors. (Bug#40760)

On Windows, starting the server with an invalid value for innodb_flush_method caused a crash. (Bug#40757)

When archive tables were joined on their primary keys, a query returned no result if the optimizer chose to use this index. (Bug#40677)

MySQL 5.1 crashed with index merge algorithm and merge tables.

A query in the MyISAM merge table caused a crash if the index merge algorithm was being used. (Bug#40675)

SELECT statements could be blocked by INSERT DELAYED statements that were waiting for a lock, even with low_priority_updates enabled. (Bug#40536)

If a RESTORE operation was in progress on a master server, slaves were not prohibited from starting replication of the master. (Bug#40434)

TRUNCATE TABLE for an InnoDB table did not flush cached queries for the table. (Bug#40386)

For InnoDB tables that used ROW_FORMAT=REDUNDANT, storage size of NULL columns could be determined incorrectly. (Bug#40369)

When building Falcon as a plugin, the plugin would be installed into the wrong directory and would fail to be located when trying to install the plugin. (Bug#40336)

“Backup completed” was logged for nonsuccessful BACKUP DATABASE operations. “Restore completed” was logged for nonsuccessful RESTORE operations. (Bug#40305)

The internal dependency mechanism for handling records and transactions within Falcon has been updated. This fixes a number of issues with transactions and concurrent workloads within Falcon tables. (Bug#40274, Bug#36410)

The query cache stored only partial query results if a statement failed while the results were being sent to the client. This could cause other clients to hang when trying to read the cached result. Now if a statement fails, the result is not cached. (Bug#40264)

The ':' character was incorrectly disallowed in table names. (Bug#40104)

For an InnoDB table, DROP TABLE or ALTER TABLE ... DISCARD TABLESPACE could take a long time or cause a server crash. (Bug#39939)

Threads were set to the Table lock state in such a way that use of this state by other threads to check for a lock wait was subject to a race condition. (Bug#39897)

When a MEMORY table became full, the error generated was returned to the client but was not written to the error log. (Bug#39886)

For a server started with the --temp-pool option on Windows, temporary file creation could fail. This option now is ignored except on Linux systems, which was its original intended scope. (Bug#39750)

The implementation of the backup_wait_timeout system variable was machine dependent and did not work correctly on big-endian machines. (Bug#39749, Bug#40808)

ALTER TABLE on a table with FULLTEXT index that used a pluggable FULLTEXT parser could cause debug servers to crash. (Bug#39746)

When performing concurrent DROP INDEX and INSERT or UPDATE operations on a Falcon table, an assertion could occur when recovering from a crashed instance. (Bug#39678)

The server crashed if an integer field in a CSV file did not have delimiting quotes. (Bug#39616)

InnoDB could hang trying to open an adaptive hash index. (Bug#39483)

Queries with that end with ... WHERE condition ORDER BY index_columns LIMIT N could produce rows that did not match the WHERE clause for certain kinds of conditions and table data distributions. (Bug#39447)

The internal buffering logic for BACKUP DATABASE had a problem that could lead to corrupt backup images. (Bug#39375)

A bad pointer dereference caused BACKUP DATABASE to crash. (Bug#39361)

INFORMATION_SCHEMA access optimizations did not work properly in some cases. (Bug#39270)

Cardinality for merge tables kept approaching zero in myrg_attach_children() because m_info->rec_per_key_part was initialized to 0 only when the function was first called. (Bug#39185)

The expression ROW(...) IN (SELECT ... FROM DUAL) always returned TRUE. (Bug#39069)

When the Falcon storage engine encountered an I/O error, mysqld would crash. Errors now raise an exception, which is reported to the error log and Falcon will fail to initialize. (Bug#38970, Bug#41545)

SELECT * FROM INFORMATION_SCHEMA.ROUTINES could fail if there was no default database. (Bug#38916)

InnoDB could fail to generate AUTO_INCREMENT values after an UPDATE statement for the table. (Bug#38839)

The greedy optimizer could cause a server crash due to improper handling of nested outer joins. (Bug#38795)

Use of COUNT(DISTINCT) prevented NULL testing in the HAVING clause. (Bug#38637)

Building MySQL on FreeBSD would result in a failure during the gen_lex_hash phase of the build. (Bug#38364)

A mix of TRUNCATE TABLE with LOCK TABLES and UNLOCK TABLES for an InnoDB could cause a server crash. (Bug#38231)

The ExtractValue() function did not work correctly with XML documents containing a DOCTYPE declaration. (Bug#38227)

The innodb_stats_on_metadata system variable was not displayed by SHOW VARIABLES and was not settable at runtime. (Bug#38189)

Enabling the sync_frm system variable had no effect on the handling of .frm files for views. (Bug#38145)

Use of spatial data types in prepared statements could cause memory leaks or server crashes. (Bug#37956, Bug#37671)

An error in a debugging check caused crashes in debug servers. (Bug#37936)

An initialization procedure for materialized subquery execution was not called due to an early optimization of MIN()/MAX() queries. (Bug#37896)

The presence of a /* ... */ comment preceding a query could cause InnoDB to use unnecessary gap locks. (Bug#37885)

An assertion failure could occur when trying to execute a query with a subquery such that one of the subquery's tables was accessed using the DS-MRR access method. (Bug#37842)

For comparison of NULL to a subquery result inside IS NULL, the comparison could evaluate to NULL rather than to TRUE or FALSE. This occurred for expressions such as:

SELECT ... WHERE NULL IN (SELECT ...) IS NULL

(Bug#37822)

When using ALTER TABLE on an InnoDB table, the AUTO_INCREMENT value could be changed to an incorrect value. (Bug#37788)

Setting myisam_repair_threads greater than 1 caused a server crash for table repair or alteration operations for MyISAM tables with multiple FULLTEXT indexes. (Bug#37756)

Primary keys were treated as part of a covering index even if only a prefix of a key column was used. (Bug#37742)

The MONTHNAME() and DAYNAME() functions returned a binary string, so that using LOWER() or UPPER() had no effect. Now MONTHNAME() and DAYNAME() return a value in character_set_connection character set. (Bug#37575)

The internal-use-only filename character set was visible in the output of some SHOW statements and in the contents of the COLLATION_CHARACTER_SET_APPLICABILITY table of INFORMATION_SCHEMA. (Bug#37554)

Storing TIMESTAMP values in Falcon tables on a machine supporting big endian storage (for example SPARC), the time stamp information returned would be incorrect. (Bug#37281)

Certain boolean-mode FULLTEXT searches that used the truncation operator did not return matching records and calculated relevance incorrectly. (Bug#37245)

Previously, InnoDB performed REPLACE INTO T SELECT ... FROM S WHERE ... by setting shared next-key locks on rows from S. Now InnoDB selects rows from from S with shared locks or as a consistent read, as for INSERT ... SELECT. This reduces lock contention between sessions. (Bug#37232)

When creating an index on a Falcon table with a very large dataset, mysqld would crash. (Bug#37056)

For an InnoDB table with a FOREIGN KEY constraint, TRUNCATE TABLE may be performed using row by row deletion. If an error occurred during this deletion, the table would be only partially emptied. Now if an error occurs, the truncation operation is rolled back and the table is left unchanged. (Bug#37016)

Subquery materialization produced incorrect results when comparing different types. (Bug#36752)

An argument to the MATCH() function that was an alias for an expression other than a column name caused a server crash. (Bug#36737)

Previously, statements inside a stored program did not clear the warning list. For example, warnings or errors generated by statements within a trigger or stored function would be accumulated and added to the message list for the statement that activated the trigger or invoked the function, “polluting” the output of SHOW WARNINGS or SHOW ERRORS for the outer statement. Normally, messages for a statement that can generate messages replace messages from the previous such statement. The effect was that a statement could have a different effect on the message list depending on whether it executed inside or outside of a stored program.

Now within a stored program, successive statements that can generate messages update the message list and replace messages from the previous such statement. Only messages from the last of these statements is copied to the message list for the outer statement. (Bug#36649)

myisampack --join did not create the destination table .frm file. (Bug#36573)

When parsing or formatting interval values of DAY_MICROSECOND type, fractional seconds were not handled correctly when more-significant fields were implied or omitted. (Bug#36466)

comp_err sometimes crashed due to improper mutex use. (Bug#36428)

The mysql client sometimes improperly interpreted string escape sequences in nonstring contexts. (Bug#36391)

The query cache stored packets containing the server status of the time when the cached statement was run. This might lead to an incorrect transaction status on the client side if a statement was cached during a transaction and later served outside a transaction context (or vice versa). (Bug#36326)

Some error numbers were incorrect. (Bug#36062)

For upgrades to MySQL 5.1 or higher, mysql_upgrade did not re-encode database or table names that contained nonalphanumeric characters. (They would still appear after the upgrade with the #mysql50# prefix described in Section 8.2.3, “Mapping of Identifiers to File Names”.) To correct this problem, it was necessary to run mysqlcheck --all-databases --check-upgrade --fix-db-names --fix-table-names manually. mysql_upgrade now runs that command automatically after performing the initial upgrade. (Bug#35934)

SHOW CREATE TABLE did not display a printable value for the default value of BIT columns. (Bug#35796)

The max_length metadata value was calculated incorrectly for the FORMAT() function, which could cause incorrect result set metadata to be sent to clients. (Bug#35558)

InnoDB could fail to generate AUTO_INCREMENT values if rows previously had been inserted containing literal values for the AUTO_INCREMENT column. (Bug#35498, Bug#36411, Bug#39830)

Result set metadata for columns retrieved from INFORMATION_SCHEMA tables did not have the db or org_table members of the MYSQL_FIELD structure set. (Bug#35428)

If the system time was adjusted backward during query execution, the apparent execution time could be negative. But in some cases these queries would be written to the slow query log, with the negative execution time written as a large unsigned number. Now statements with apparent negative execution time are not written to the slow query log. (Bug#35396)

The CREATE_OPTIONS column for INFORMATION_SCHEMA.TABLES did not display the KEY_BLOCK_SIZE option. (Bug#35275)

On Windows, the _PC macro in my_global.h was causing problems for modern compilers. It has been removed because it is no longer used. (Bug#34309)

For DROP FUNCTION with names that were qualified with a database name, the database name was handled in case-sensitive fashion even with lower_case_table_names set to 1. (Bug#33813)

The mysql client incorrectly parsed statements containing the word “delimiter” in mid-statement. (Bug#33812)

See also Bug#38158.

Falcon would allow you to explicitly create a table within the internal FALCON_TEMPORARY tablespace. You can no longer explicitly select the FALCON_TEMPORARY tablespace. (Bug#33720)

It was possible to set Falcon memory parameters to values larger than the maximum memory supported by the supported by the host environment. (Bug#33583)

The mysqldump command would not include the TABLESPACE information for Falcon tables within the dump information. (Bug#33148)

Three conditions were discovered that could cause an upgrade from MySQL 5.0 to 5.1 to fail: 1) Triggers associated with a table that had a #mysql50# prefix in the name could cause assertion failure. 2) ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME failed for databases that had a #mysql50# prefix if there were triggers in the database. 3) mysqlcheck --fix-table-name didn't use UTF8 as the default character set, resulting in parsing errors for tables with nonlatin symbols in their names and trigger definitions. (Bug#33094, Bug#41385)

libmysqld was not built with all character sets. (Bug#32831)

Queries with dependent subqueries were slow. (Bug#32665)

Falcon would allow you to create a Falcon TABLESPACE with the same filename as existing datafiles (including datafiles of other engines). All Falcon tablespaces are now created with a .fts extension, regardless of the specified filename. (Bug#32398)

For mysqld_multi, using the --mysqld=mysqld_safe option caused the --defaults-file and --defaults-extra-file options to behave the same way. (Bug#32136)

Attempts to open a valid MERGE table sometimes resulted in a ER_WRONG_MRG_TABLE error. This happened after failure to open an invalid MERGE table had also generated an ER_WRONG_MRG_TABLE error. (Bug#32047)

Queries executed using join buffering of BIT columns could produce incorrect results. (Bug#31399)

ALTER TABLE CONVERT TO CHARACTER SET did not convert TINYTEXT or MEDIUMTEXT columns to a longer text type if necessary when converting the column to a different character set. (Bug#31291)

Server variables could not be set to their current values on Linux platforms. (These fixes are in addition to those made in MySQL 6.0.5 and 6.0.9.) (Bug#31177)

See also Bug#6958.

ALTER TABLE statements that added a column and added a nonpartial index on the column failed to add the index. (Bug#31031)

mysqld --help did not work as root. (Bug#30261)

Static storage engines and plugins that were disabled and dynamic plugins that were installed but disabled were not listed in the INFORMATION_SCHEMA appropriate PLUGINS or ENGINES table. (Bug#29263)

On Windows, Visual Studio does not take into account some x86 hardware limitations, which led to incorrect results converting large DOUBLE values to unsigned BIGINT values. (Bug#27483)

If the default database was dropped, the value of character_set_database was not reset to character_set_server as it should have been. (Bug#27208)

SSL support was not included in some “generic” RPM packages. (Bug#26760)

SHOW TABLE STATUS could fail to produce output for tables with non-ASCII characters in their name. (Bug#25830)

DROP TABLE for INFORMATION_SCHEMA tables produced an Unknown table error rather than the more appropriate Access denied. (Bug#24062)

Allocation of stack space for error messages could be too small on HP-UX, leading to stack overflow crashes. (Bug#21476)

For the DIV operator, incorrect results could occur for noninteger operands that exceed BIGINT range. Now, if either operand has a noninteger type, the operands are converted to DECIMAL and divided using DECIMAL arithmetic before converting the result to BIGINT. If the result exceeds BIGINT range, an error occurs. (Bug#8457)

BACKUP DATABASE and RESTORE now indicate in the server's error log which databases are being backed up or restored. (Bug#40307)

Performance of SELECT * retrievals from INFORMATION_SCHEMA.COLUMNS was improved slightly. (Bug#38918)

Previously, index hints did not work for FULLTEXT searches. Now they work as follows:

For natural language mode searches, index hints are silently ignored. For example, IGNORE INDEX(i) is ignored with no warning and the index is still used.

For boolean mode searches, index hints with FOR ORDER BY or FOR GROUP BY are silently ignored. Index hints with FOR JOIN or no FOR modifier are honored. In contrast to how hints apply for non-FULLTEXT searches, the hint is used for all phases of query execution (finding rows and retrieval, grouping, and ordering). This is true even if the hint is given for a non-FULLTEXT index. (Bug#38842)

MySQL support for adding collations using LDML specifications did not support the <i> identity rule that indicates one character sorts identically to another. The <i> rule now is supported. (Bug#37129)

Previously, RESTORE overwrote any databases with information from the backup image. Now, RESTORE aborts with an error if the backup image contains any databases that currently exist on the server, unless the optional keyword OVERWRITE is given following the image file name. (Bug#34579)

A new statement, PURGE BACKUP LOGS, enables the contents of the MySQL Backup logs to be culled. See Section 12.5.3.2, “PURGE BACKUP LOGS Syntax”. (Bug#33364)

A new algorithm that uses both index access to the joined table and a join buffer has been implemented. It is called the Batched Key Access (BKA) Join algorithm. The algorithm supports inner join, outer join and semi-join operations, including nested outer joins and nested semi-joins. Also, the Block Nested-Loop (BNL) Join algorithm previously used only for inner joins has been extended and can be employed for outer join and semi-join operations, including nested nested outer joins and nested semi-joins. For more information, see Section 7.2.15, “Block Nested-Loop and Batched Key Access Joins”.

In conjunction with this work, there is a new system variable, join_cache_level, that controls how join buffering is done.

Security Enhancement: When the DATA DIRECTORY or INDEX DIRECTORY clause of a CREATE TABLE statement referred to a subdirectory of the data directory via a symlinked component of the data directory path, it was accepted, when for security reasons it should be rejected. (Bug#39277)

Incompatible Change: CHECK TABLE ... FOR UPGRADE did not check for collation changes made in MySQL 6.0.1 to latin2_czech_cs (Bug#25420) or collation changes made in MySQL 6.0.6 to big5_chinese_ci, cp866_general_ci, gb2312_chinese_ci, and gbk_chinese_ci. This also affects mysqlcheck and mysql_upgrade, which cause that statement to be executed. See Section 2.11.3, “Checking Whether Table Indexes Must Be Rebuilt”. (Bug#40054)

Partitioning: Replication: Changing the transaction isolation level while replicating partitioned InnoDB tables could cause statement-based logging to fail. (Bug#39084)

Partitioning: This bug was introduced in MySQL 6.0.5. (Bug#40954)

This regression was introduced by Bug#30573, Bug#33257, Bug#33555.

Partitioning: With READ COMMITTED transaction isolation level, InnoDB uses a semi-consistent read that releases nonmatching rows after MySQL has evaluated the WHERE clause. However, this was not happening if the table used partitions. (Bug#40595)

Partitioning: A SELECT using a range WHERE condition with an ORDER BY on a partitioned table caused a server crash. (Bug#40494)

Partitioning: For a partitioned table having an AUTO_INCREMENT column: If the first statement following a start of the server or a FLUSH TABLES statement was an UPDATE statement, the AUTO_INCREMENT column was not incremented correctly. (Bug#40176)

Partitioning: The server attempted to execute the statements ALTER TABLE ... ANALYZE PARTITION, ALTER TABLE ... CHECK PARTITION, ALTER TABLE ... OPTIMIZE PARTITION, and ALTER TABLE ... REORGANIZE PARTITION on tables that were not partitioned. (Bug#39434)

See also Bug#20129.

Partitioning: The value of the CREATE_COLUMNS column in INFORMATION_SCHEMA.TABLES was not partitioned for partitioned tables. (Bug#38909)

Partitioning: When executing an ORDER BY query on a partitioned InnoDB table using an index that was not in the partition expression, the results were sorted on a per-partition basis rather than for the table as a whole. (Bug#37721)

Partitioning: Partitioned table checking sometimes returned a warning with an error code of 0, making proper response to errors impossible. The fix also renders the error message subject to translation in non-English deployments. (Bug#36768)

Partitioning: When SHOW CREATE TABLE was used on a partitioned table, all of the table's PARTITION and SUBPARTITION clauses were output on a single line, making it difficult to read or parse. (Bug#14326)

Replication: Row-based replication failed with nonpartitioned MyISAM tables having no indexes. (Bug#40004)

An assertion failure occurred for a join query when a small size of the join buffer was set and the value of record_per_key for the index used for a ref access with this join buffer was big enough. (Bug#41204)

Unique indexes on FALCON tables can not be created when the column is NOT NULL. (Bug#40994)

Accessing user variables within triggers could cause a server crash. (Bug#40770)

For single-table UPDATE statements, an assertion failure resulted from a runtime error in a stored function (such as a recursive function call or an attempt to update the same table as in the UPDATE statement). (Bug#40745)

Date values of 000-00-00 inserted into a FALCON table were incorrectly recognized and returned when performing a SELECT on a field with an index. (Bug#40614)

Several MySQL Backup-related memory-use issues identified by Valgrind were corrected. (Bug#40480)

When executing concurrent CREATE TABLE ... SELECT statements on a Maria table, the error Error: Memory allocated at trnman.c:129 was underrun, discovered at ma_close.c:65 error would be logged in the error file, and the server would eventually crash. (Bug#40416)

Prepared statements allowed invalid dates to be inserted when the ALLOW_INVALID_DATES SQL mode was not enabled. (Bug#40365)

With statement-based binary logging format and a transaction isolation level of READ COMMITTED or stricter, InnoDB printed an error because statement-based logging might lead to inconsistency between master and slave databases. However, this error was printed even when binary logging was not enabled (in which case, no such inconsistency can occur). (Bug#40360)

A query with an outer join where the ON expression evaluated to the constant FALSE could return incorrect results when a join buffer was used for the outer join operation. (Bug#40317)

Errors from a BACKUP DATABASE or RESTORE operation were shown by SHOW WARNINGS as warnings, not errors. (Bug#40304)

If several errors occurred during a BACKUP DATABASE or RESTORE operation, the final error was returned to the client, even though the first error is usually more pertinent. (Bug#40303)

Creation of a tablespace file within FALCON could create a tablespace entry in the INFORMATION_SCHEMA.FALCON_TABLESPACE_IO even the underlying data file had not been created. (Bug#40302)

Specifying the --log-backup-output option without an argument set the destination for the backup logs to FILE rather than to the default of TABLE. (Bug#40282)

mc.exe is no longer needed to compile MySQL on Windows. This makes it possible to build MySQL from source using Visual Studio Express 2008. (Bug#40280)

The server could generate extra rows in the result set for a query with a nested outer join if the inner tables of the outer join were joined using join buffers. (Bug#40268)

If BACKUP DATABASE was used to back up an empty database and binary logging enabled, the backup image was flagged as containing binary log information even though it did not. Using RESTORE with the backup image then crashed trying to parse the binary log file name. (Bug#40262)

The backup_history_log_file and backup_progress_log_file system variables were not settable at server startup. Now they are. (Bug#40219)

The default value of the backup_history_log and backup_progress_log system variables is ON, but explicitly setting them to DEFAULT set them to OFF. (Bug#40218)

When an outer join employed a join buffer to join the first inner table by the Blocked Nested-Loop algorithm, extra NULL-complemented rows could be generated if the WHERE clause contained conditions that can be pushed down to this table. (Bug#40192)

When the optimizer joined an inner table of an outer join using both “not exists” optimization and a join buffer, an incorrect result set could be returned. (Bug#40134)

Support for the revision field in .frm files has been removed. This addresses the downgrading problem introduced by the fix for Bug#17823. (Bug#40021)

The MySQL Backup message logger caused an assertion failure. (Bug#39997)

Retrieval speed from the following INFORMATION_SCHEMA tables was improved by shortening the VARIABLE_VALUE column to 1024 characters: GLOBAL_VARIABLES, SESSION_VARIABLES, GLOBAL_STATUS, and SESSION_STATUS.

As a result of this change, any variable value longer than 1024 characters will be truncated with a warning. This affects only the init_connect system variable. (Bug#39955)

If the operating system is configured to return leap seconds from OS time calls or if the MySQL server uses a time zone definition that has leap seconds, functions such as NOW() could return a value having a time part that ends with :59:60 or :59:61. If such values are inserted into a table, they would be dumped as is by mysqldump but considered invalid when reloaded, leading to backup/restore problems.

Now leap second values are returned with a time part that ends with :59:59. This means that a function such as NOW() can return the same value for two or three consecutive seconds during the leap second. It remains true that literal temporal values having a time part that ends with :59:60 or :59:61 are considered invalid.

For additional details about leap-second handling, see Section 9.7.2, “Time Zone Leap Second Support”. (Bug#39920)

The server could crash during a sort-order optimization of a dependent subquery. (Bug#39844)

Recovery of a tablespace for FALCON tables could fail if the tablespace was already in use. (Bug#39789)

Creating a FALCON table while specifying a specific tablespace and partition to be used for the table will fail if the specified tablespace does not already exist, returning a error indicating general table creation failure. The message has been updated to indicate that the failure is due to nonexistent tablespace. (Bug#39702)

With the ONLY_FULL_GROUP_BY SQL mode enabled, the check for nonaggregated columns in queries with aggregate functions, but without a GROUP BY clause was treating all the parts of the query as if they were in the select list. This is fixed by ignoring the nonaggregated columns in the WHERE clause. (Bug#39656)

Concurrent execution of BACKUP DATABASE and DML operations on MyISAM tables could produce a deadlock. (Bug#39602)

The do_abi_check program run during the build process depends on mysql_version.h but that file was not created first, resulting in build failure. (Bug#39571)

CHECK TABLE failed for MyISAM INFORMATION_SCHEMA tables. (Bug#39541)

On 64-bit Windows systems, the server accepted key_buffer_size values larger than 4GB, but allocated less. (For example, specifying a value of 5GB resulted in 1GB being allocated.) (Bug#39494)

Compiling MySQL with FALCON support enabled with a compiler that does not support exceptions would fail to complete successfully. configure has been updated to switch off FALCON support if the specified compiler does not support exceptions. (Bug#39419)

Use of the PACK_KEYS or MAX_ROWS table option in ALTER TABLE should have triggered table reconstruction but did not. (Bug#39372)

The server returned a column type of VARBINARY rather than DATE as the result from the COALESCE(), IFNULL(), IF(), GREATEST(), or LEAST() functions or CASE expression if the result was obtained using filesort in an anonymous temporary table during the query execution. (Bug#39283)

Starting MySQL with FALCON support when MySQL has not been compiled with a compiler supporting exceptions would lead to strange errors and results. MySQL will now fail to initialize if you have compiled without exceptions enabled with the following message:

081116 12:21:12 [ERROR] Falcon must be compiled with C++ exceptions enabled to work. Please adjust your compile flags.
[Falcon] Error: Falcon exiting process

(Bug#39260)

A server built using yaSSL for SSL support would crash if configured to use an RSA key and a client sent a cipher list containing a non-RSA key as acceptable. (Bug#39178)

When built with Valgrind, the server failed to access tables created with the DATA DIRECTORY or INDEX DIRECTORY table option. (Bug#39102)

With binary logging enabled CREATE VIEW was subject to possible buffer overwrite and a server crash. (Bug#39040)

The fast mutex implementation was subject to excessive lock contention. (Bug#38941)

Use of InnoDB monitoring (SHOW ENGINE INNODB STATUS or one of the InnoDB Monitor tables) could cause a server crash due to invalid access to a shared variable in a concurrent environment. (Bug#38883)

Column names constructed due to wild-card expansion done inside a stored procedure could point to freed memory if the expansion was performed after the first call to the stored procedure. (Bug#38823)

If delayed insert failed to upgrade the lock, it did not free the temporary memory storage used to keep newly constructed BLOB values in memory, resulting in a memory leak. (Bug#38693)

The server unnecessarily acquired a query cache mutex even with the query cache disabled, resulting in a small performance decrement. (Bug#38551)

On Windows, a five-second delay occurred at shutdown of applications that used the embedded server. (Bug#38522)

On Solaris, a scheduling policy applied to the main server process could be unintentionally overwritten in client-servicing threads. (Bug#38477)

BACKUP DATABASE failed to use the native driver for a Falcon table if the table was partitioned. (Bug#38426)

On Windows, the embedded server would crash in mysql_library_init() if the language file was missing. (Bug#38293)

The Event Scheduler no longer logs “started in thread” or “executed” successfully messages to the error log. (Bug#38066)

Setting the debug system variable and executing a SELECT statement resulted in a Valgrind warning. (Bug#38023)

An incorrectly checked XOR subquery optimization resulted in an assertion failure. (Bug#37899)

A SELECT with a NULL NOT IN condition containing a complex subquery from the same table as in the outer select caused an assertion failure. (Bug#37894)

Use of an uninitialized constant in EXPLAIN evaluation caused an assertion failure. (Bug#37870)

The server did not shut down upon receipt of a SIGINT signal unless it was run within a debugger. (Bug#37869)

A query that could use one index to produce the desired ordering and another index for range access with index condition pushdown could cause a server crash. (Bug#37851)

Renaming an ARCHIVE table to the same name with different lettercase and then selecting from it could cause a server crash. (Bug#37719)

For queries executed with the batched-key access method, an incorrect value of an internal parameter caused a server crash if join_buffer_size was less then 256. (Bug#37690)

Compiling MySQL with FALCON support enabled on Solaris 9 using the Sun Studio compiler would fail with error:

"Interlock.h", line 149: Error: #error cas not defined. We need>= Solaris 10.

(Bug#37622)

TIMEDIFF() was erroneously treated as always returning a positive result. Also, CAST() of TIME values to DECIMAL dropped the sign of negative values. (Bug#37553)

See also Bug#42525.

mysqlcheck used SHOW FULL TABLES to get the list of tables in a database. For some problems, such as an empty .frm file for a table, this would fail and mysqlcheck then would neglect to check other tables in the database. (Bug#37527)

Updating a view with a subquery in the CHECK option could cause an assertion failure. (Bug#37460)

Statements that displayed the value of system variables (for example, SHOW VARIABLES) expect variable values to be encoded in character_set_system. However, variables set from the command line such as basedir or datadir were encoded using character_set_filesystem and not converted correctly. (Bug#37339)

On a 32-bit server built without big tables support, the offset argument in a LIMIT clause might be truncated due to a 64-bit to 32-bit cast. (Bug#37075)

Specifying a database name twice to BACKUP DATABASE caused a server crash. Now BACKUP DATABASE ignores duplicate names. (Bug#36933)

If a nondirectory file f without an extension was created in the data directory, the server would allow clients to execute a USE f statement even though f could not be a database. The server now verifies that that the named database corresponds to a directory. (Bug#36897)

The FALCON storage would silently recreate missing tablespace files if they did not exist. Errors are now written to the MySQL error log when the FALCON system tablespace files are found to be missing. Warnings are produce in the log file when attempting to access data tablespace files that do not exist. (Bug#36804)

Use of CONVERT() with GROUP BY to convert numeric values to CHAR could return truncated results. (Bug#36772)

The mysql client, when built with Visual Studio 2005, did not display Japanese characters. (Bug#36279)

Setting the slave_compressed_protocol system variable to DEFAULT failed in the embedded server. (Bug#35999)

Processing for NULL-complemented rows in the result sets of queries with nested outer joins could be incorrect. (Bug#35835)

The columns that store character set and collation names in several INFORMATION_SCHEMA tables were lengthened because they were not long enough to store some possible values: SCHEMATA, TABLES, COLUMNS, CHARACTER_SETS, COLLATIONS, and COLLATION_CHARACTER_SET_APPLICABILITY. (Bug#35789)

Queries executed using the batched-key access method could cause an assertion fail when key expressions for a ref access depended on columns not only from the previous join table. (Bug#35685)

Selecting from an INFORMATION_SCHEMA table into an incorrectly defined MERGE table caused an assertion failure. (Bug#35068)

perror on Windows did not know about Win32 system error codes. (Bug#34825)

EXPLAIN EXTENDED evaluation of aggregate functions that required a temporary table caused a server crash. (Bug#34773)

BACKUP DATABASE produced an incorrect error message when the backup image file name contained a nonexistent directory. (Bug#34754)

SHOW GLOBAL STATUS shows values that aggregate the session status values for all threads. This did not work correctly for the embedded server. (Bug#34517)

There were spurious warnings about "Truncated incorrect DOUBLE value" in queries with MATCH ... AGAINST and > or < with a constant (which was reported as an incorrect DOUBLE value) in the WHERE condition. (Bug#34374)

mysqldumpslow did not aggregate times. (Bug#34129)

mysql_config did not output -ldl (or equivalent) when needed for --libmysqld-libs, so its output could be insufficient to build applications that use the embedded server. (Bug#34025)

For a stored procedure containing a SELECT * ... RIGHT JOIN query, execution failed for the second call. (Bug#33811)

The CSV storage engine had been modified to require columns to be explicitly specified as NOT NULL in CREATE TABLE statements.

However, adding columns via the ALTER TABLE command allowed nullable columns to be added to an existing CSV table. (Bug#33696)

The ROUTINES.DATA_TYPE, REFERENTIAL_CONSTRAINTS.SPECIFIC_SCHEMA, REFERENTIAL_CONSTRAINTS.SPECIFIC_NAME, REFERENTIAL_CONSTRAINTS.PARAMETER_NAME, REFERENTIAL_CONSTRAINTS.DATA_TYPE columns were declared longer than the maximum allowed identifier length. (Bug#33649)

If a TEMPORARY table existed with the same name as a regular table, BACKUP DATABASE saved the temporary table, causing a subsequent RESTORE to fail. (Bug#33574)

Previously, use of index hints with views (which do not have indexes) produced the error ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX and VIEW. Now this produces ERROR 1176 (HY000): Key '...' doesn't exist in table '...', the same error as for base tables without an appropriate index. (Bug#33461)

Execution of a prepared statement that referred to a system variable caused a server crash. (Bug#32124)

Some division operations produced a result with incorrect precision. (Bug#31616)

Server variables could not be set to their current values on Linux platforms. (These fixes are in addition to those made in MySQL 6.0.5; additional fixes were made in MySQL 6.0.10.) (Bug#31177)

See also Bug#6958.

For Solaris package installation using pkgadd, the postinstall script failed, causing the system tables in the mysql database not to be created. (Bug#31164)

For installation on Solaris using pkgadd packages, the mysql_install_db script was generated in the scripts directory, but the temporary files used during the process were left there and not deleted. (Bug#31052)

Searching for text values on a column using a character set that provides multi-weight characters and sequences on an INNODB or FALCON table with an index would fail to find the expanded value. (Bug#29246)

Some SHOW statements and retrievals from the INFORMATION_SCHEMA TRIGGERS and EVENTS tables used a temporary table and incremented the Created_tmp_disk_tables status variable, due to the way that TEXT columns are handled. The TRIGGERS.SQL_MODE, TRIGGERS.DEFINER, and EVENTS.SQL_MODE columns now are VARCHAR to avoid this problem. (Bug#29153)

XA transaction rollbacks could result in corrupted transaction states and a server crash. (Bug#28323)

There were cases where string-to-number conversions would produce warnings for CHAR values but not for VARCHAR values. (Bug#28299)

For several read only system variables that were viewable with SHOW VARIABLES, attempting to view them with SELECT @@var_name or set their values with SET resulted in an unknown system variable error. Now they can be viewed with SELECT @@var_name and attempting to set their values results in a message indicating that they are read only. (Bug#28234)

ALTER TABLE for an ENUM column could change column values. (Bug#23113)

Setting the session value of the max_allowed_packet or net_buffer_length system variable was allowed but had no effect. The session value of these variables is now read only. (Bug#22891)

A race condition between the mysqld.exe server and the Windows service manager could lead to inability to stop the server from the service manager. (Bug#20430)

Incompatible Change: The tables for MySQL Backup logging have been renamed, and the logging capabilities now are more flexible, similar to the capabilities provided for the general query log and slow query log.

Important Change: The --skip-thread-priority option is now deprecated in MySQL 5.1 and is removed in MySQL 6.0 such that the server won't change the thread priorities by default. Giving threads different priorities might yield marginal improvements in some platforms (where it actually works), but it might instead cause significant degradation depending on the thread count and number of processors. Meddling with the thread priorities is a not a safe bet as it is very dependent on the behavior of the CPU scheduler and system where MySQL is being run. (Bug#35164, Bug#37536)

Important Change: The --log option now is deprecated and will be removed (along with the log system variable) in the future. Instead, use the --general_log option to enable the general query log and the --general_log_file=file_name option to set the general query log file name. The values of these options are available in the general_log and general_log_file system variables, which can be changed at runtime.

Similar changes were made for the --log-slow-queries option and log_slow_queries system variable. You should use the --slow_query_log and --slow_query_log_file=file_name options instead (and the slow_query_log and slow_query_log_file system variables).

The BUILD/compile-solaris-* scripts now compile MySQL with the mtmalloc library rather than malloc. (Bug#38727)

Binary distributions for Solaris, Linux, and Mac OS X now are built with support for the pool-of-threads value of thread_handling. (Bug#38636)

BACKUP DATABASE now performs an implicit commit, like RESTORE. (Bug#38261)

The deprecated --default-table-type server option has been removed. (Bug#34818)

On WIndows, use of POSIX I/O interfaces in mysys was replaced with Win32 API calls (CreateFile(), WriteFile(), and so forth) and the default maximum number of open files has been increased to 16384. The maximum can be increased further by using the --open-files-limit=N option at server startup. (Bug#24509)

Previously, prepared CALL statements could be used via the C API only for stored procedures that produce at most one result set, and applications could not use placeholders for OUT or INOUT parameters. For prepared CALL statements used via PREPARE and EXECUTE, placeholders could not be used for OUT or INOUT parameters.

For the C API, prepared CALL support now is expanded in the following ways:

For PREPARE and EXECUTE, placeholder support for OUT and INOUT parameters is now available. See Section 12.2.1, “CALL Syntax”. (Bug#11638, Bug#17898)

MySQL now supports an interface for semisynchronous replication: A commit performed on the master side blocks before returning to the session that performed the transaction until at least one slave acknowleges that it has received and logged the events for the transaction. Semisynchronous replication is implemented through an optional plugin component. See Section 16.2.9, “Semisynchronous Replication”

Most statements that previously caused an implicit commit before executing now also cause an implicit commit after executing. Also, the FLUSH statement and mysql_refresh() C API function now cause an implicit commit. See Section 12.4.3, “Statements That Cause an Implicit Commit”.

The FILES and TABLESPACES tables have been added to INFORMATION_SCHEMA for tracking the individual files and tablespace details for Falcon. In addition, the TABLES table has been extended to incorporate the TABLESPACE_NAME field to specify the tablespace name that a specific table belongs to.

Incompatible Change: CHECK TABLE ... FOR UPGRADE did not check for incompatible collation changes made in MySQL 5.1.21 (Bug#29499) and 5.1.23 (Bug#27562, Bug#29461). This also affects mysqlcheck and mysql_upgrade, which cause that statement to be executed. See Section 2.11.3, “Checking Whether Table Indexes Must Be Rebuilt”. (Bug#39585)

See also Bug#40984.

Incompatible Change: In connection with view creation, the server created arc directories inside database directories and maintained useless copies of .frm files there. Creation and renaming procedures of those copies as well as creation of arc directories has been discontinued.

This change does cause a problem when downgrading to older server versions which manifests itself under these circumstances:

As a workaround to avoid this problem, use either of these approaches:

The downgrade problem introduced by the fix for this bug has been addressed as Bug#40021. (Bug#17823)

Important Change: Replication: The SUPER privilege is now required to change the session value of binlog_format as well as its global value. For more information about binlog_format, see Section 16.1.2, “Replication Formats”. (Bug#39106)

Partitioning: Replication: Replication to partitioned MyISAM tables could be slow with row-based binary logging. (Bug#35843)

Partitioning: A duplicate key error raised when inserting into a partitioned table used a different error code from that returned by such an error raised when inserting into a table that was not partitioned. (Bug#38719)

See also Bug#28842.

Partitioning: If an error occurred when evaluating a column of a partitioned table for the partitioning function, the row could be inserted anyway. (Bug#38083)

Partitioning: Using INSERT ... SELECT to insert records into a partitioned MyISAM table could fail if some partitions were empty and others are not. (Bug#38005)

Replication: Issuing the statement CHANGE MASTER TO ... MASTER_HEARTBEAT_PERIOD = period using a value for period outside the permitted range caused the slave to crash. (Bug#39077)

Replication: Replication of BLACKHOLE tables did not work with row-based binary logging. (Bug#38360)

Replication: In some cases, a replication master sent a special event to a reconnecting slave to keep the slave's temporary tables, but they still had references to the “old” slave SQL thread and used them to access that thread's data. (Bug#38269)

Replication: Replication filtering rules were inappropiately applied when executing BINLOG pseudo-queries. One way in which this problem showed itself was that, when replaying a binary log with mysqlbinlog, RBR events were sometimes not executed if the --replicate-do-db option was specified. Now replication rules are applied only to those events executed by the slave SQL thread. (Bug#36099)

Replication: For a CREATE TABLE ... SELECT statement that creates a table in a database other than the current one, the table could be created in the wrong database on replication slaves if row-based binary logging is used. (Bug#34707)

Replication: A statement did not always commit or roll back correctly when the server was shut down; the error could be triggered by having a failing UPDATE or INSERT statement on a transactional table, causing an implicit rollback. (Bug#32709)

See also Bug#38262.

Compiling using --with-falcon on Mac OS X fails if you use CXX=gcc. You must specify that the g++ compiler should be used for C++ using CXX=g++. (Bug#41270)

When building Falcon support on Solaris 10 on the SPARC platform, falcon would not be compiled even when explicitly enabled. (Bug#40390)

Running an online DROP INDEX operation on an index using the same key on a Falcon table would fail with an assertion. (Bug#40265)

With innodb_autoinc_lock_mode set to 0 (“traditional” locking), deadlock and lock-wait timeout errors encountered while reading AUTO_INCREMENT values were being reported as a generic AUTO_INCREMENT value allocation failure. (The actual error encountered was printed in the error log.) The transaction was being rolled back but all the user saw was an AUTO_INCREMENT failure code. Now the actual locking error code is returned to the user. (Bug#40224)

Optimized builds of mysqld crashed when built with Sun Studio on SPARC platforms. (Bug#40224)

Creating a table, or selecting from a table using the FALCON storage engine and with a double quote in the name would cause an assertion failure. (Bug#40158, Bug#39388)

Windows builds were missing the MySQL Backup log tables. (Bug#40126)

The maximum value for falcon-serial-log-buffer has been reduced to 1000. (Bug#40123)

The indexes and record contents of a FALCON table could get out of synchronization during a lrge number of updates. Because FALCON returns data only if it matches both the index and record data the result sets returned could be invalid when comparing the results of an index and nonindex based SELECT. (Bug#40112, Bug#40130)

The CHECK TABLE ... FOR UPGRADE statement did not check for incompatible collation changes made in MySQL 5.1.24 (Bug#27877). This also affects mysqlcheck and mysql_upgrade, which cause that statement to be executed. See Section 2.11.3, “Checking Whether Table Indexes Must Be Rebuilt”.

Prior to this fix, a binary upgrade (performed without dumping tables with mysqldump before the upgrade and reloading the dump file after the upgrade) would corrupt tables that have indexes that use the utf8_general_ci or ucs2_general_ci collation for columns that contain 'ß' LATIN SMALL LETTER SHARP S (German). After the fix, CHECK TABLE ... FOR UPGRADE properly detects the problem and warns about tables that need repair.

However, the fix is not backward compatible and can result in a downgrading problem under these circumstances:

The solution is to dump tables with mysqldump before the downgrade and reload the dump file after the downgrade. Alternatively, drop and recreate affected indexes. (Bug#40053)

MySQL may crash during the recover of Falcon tables if the server was shutdown after a large data load. (Bug#39951)

Non-ASCII error messages were corrupted. (Bug#39949)

The Threads_created status variable was not correctly incremented when the server was started with the --thread-handling=pool-of-threads option. (Bug#39916)

When the Falcon serial log reaches a state where the serial log can no longer be written to, for example when the disk is full, or when permissions have been changed on an open log, then MySQL could crash. (Bug#39912)

On Windows Vista, RESTORE did not correctly calculate the validity point from the backup stream. (Bug#39825)

Falcon did not support online add/drop index creation on tables using a NOT NULL column. (Bug#39795)

When creating a table with the FALCON engine where the size of the key in the index was larger than supported (the error message did not signify the severity of the problem. The message and error has been updated. (Bug#39708)

Recovery of Falcon tables could crash because of an invalid or unrecognised tablespace ID. (Bug#39706)

Performing an INSERT on Maria table with a UNIQUE column, MySQL could deadlock. (Bug#39697)

Memory would be allocated for the Falcon sector cache even if the cache had been disabled (falcon_use_sectorcache). (Bug#39692)

The MySQL Backup backup_history log now contains a backup_file_path column. backup_file contains the basename and backup_file_path contains the directory of the image file path name. (Bug#39690)

Some MySQL Backup-related memory-use warnings detected by Valgrind were corrected. (Bug#39598)

Creating a table with a comment of 62 characters or longer caused a server crash. (Bug#39591)

When loading very large datasets into a Falcon table, MySQL may crash because the size of the Falcon serial log exceeds 4GB. The maximum supported size of the serial log file has been increased from a 32-bit to a 64-bit integer to handle larger log file sizes. (Bug#39575)

When recovering a crashed Falcon table when the page size had been set to 32K, MySQL could crash with an assertion. (Bug#39574)

The Sun Studio compiler failed to build debug versions of the server due to use of features specific to gcc. (Bug#39451)

When performing a recovery of a crashed Falcon table on Windows, MySQL would report an exception when then recovery process completed, even though the recovery may have completed successfully. (Bug#39421)

Performing an ALTER TABLE on a Maria table where you are changing the column name but not the type, a full table rebuild may be triggered, instead of just a simple rename. (Bug#39399)

Dropping a locked Maria table leads to an assertion failure. (Bug#39395)

For a TIMESTAMP column in an InnoDB table, testing the column with multiple conditions in the WHERE clause caused a server crash. (Bug#39353)

When using a Falcon table, equals (=) comparison of values of columns of type YEAR does not work when an index is present on the YEAR column(s). (Bug#39342)

When running TRUNCATE on a table where other threads are also trying to access the same Falcon table, a deadlock could occur between the two executing threads. (Bug#39321)

Performing a INSERT INTO ... ON DUPLICATE KEY UPDATE statement on a Maria table would fail with the error 1178: The storage engine for the table doesn't support UPDATE in WRITE CONCURRENT. (Bug#39248)

Maria could fail to find data in a table with an index on a char column. (Bug#39243)

Running ALTER TABLE PARTITION on a Maria table would lead to a crash. (Bug#39227)

Using Maria, executing FLUSH TABLES WITH READ LOCK after a LOCK TABLES statement would lead to a crash. (Bug#39226)

When using Falcon on ReiserFS file systems, the initial size of the serial log could cause problems during recovery if the size of the log file was less than 4KB. The minimum size of the serial log file has now been increased to 8KB to address the problem. (Bug#39212)

Running multiple SELECT, INSERT, UPDATE and DELETE queries on the Maria table could lead to a deadlock. (Bug#39210)

For BACKUP DATABASE, the server could add a / character to the end of the backup path, even when the path ended with a file name rather than a directory name. (Bug#39189)

The server could crash when attempting to insert duplicate empty strings into a utf8 SET column. (Bug#39186)

References to local variables in stored procedures are replaced with NAME_CONST(name, value) when written to the binary log. However, an “illegal mix of collation” error might occur when executing the log contents if the value's collation differed from that of the variable. Now information about the variable collation is written as well. (Bug#39182)

Building MySQL with Falcon support using Sun Studio 10 would fail due to GNU CC specific code within MemoryManager.h. (Bug#39181)

BACKUP DATABASE failed on PowerMac platforms due to type casting problems. (Bug#39127)

MySQL Backup was not handling several errors. (Bug#39089)

When performing online ALTER operations that change the indexes on Falcon tables, the indexes could get out of synchronization, leading to a crash. (Bug#39081)

Some warnings were being reported as errors. (Bug#39059)

Queries of the form SELECT ... REGEXP BINARY NULL could lead to a hung or crashed server. (Bug#39021)

Statements of the form INSERT ... SELECT .. ON DUPLICATE KEY UPDATE col_name = DEFAULT could result in a server crash. (Bug#39002)

Repeated CREATE TABLE ... SELECT statements, where the created table contained an AUTO_INCREMENT column, could lead to an assertion failure. (Bug#38821)

RESTORE crashed if a trigger and an event had the same name. (Bug#38810)

For deadlock between two transactions that required a timeout to resolve, all server tables became inaccessible for the duration of the deadlock. (Bug#38804)

Running multiple SELECT operations on the same Falcon table could lead to an assertion within the Transaction::initialize. The same operation could also lead to a deadlock situation on the specified table. (Bug#38739, Bug#38748)

When inserting a string into a duplicate-key error message, the server could improperly interpret the string, resulting in a crash. (Bug#38701)

A race condition between threads sometimes caused unallocated memory to be addressed. (Bug#38692)

A server crash resulted from concurrent execution of a multiple-table UPDATE that used a NATURAL or USING join together with FLUSH TABLES WITH READ LOCK or ALTER TABLE for the table being updated. (Bug#38691)

On ActiveState Perl, mysql-test-run.pl --start-and-exit started but did not exit. (Bug#38629)

Executing a light INSERT and UPDATE workload with falcon_index_chill_threshold set to 4K and falcon_record_chill_threshold set to to 4K, MySQL could crash. (Bug#38566)

A server crash resulted from execution of an UPDATE that used a derived table together with FLUSH TABLES. (Bug#38499)

Stored procedures involving substrings could crash the server on certain platforms due to invalid memory reads. (Bug#38469)

The binary log file name stored in the binlog_file column of the mysql.backup_history MySQL Backup table now is the file basename (the final component). Previously, the full path name was stored, but this could be too long for the column width. (Bug#38462)

On Windows, starting the server with the --external-locking=1 option caused BACKUP DATABASE to fail. (Bug#38342)

Inserting data into columns within a Falcon table that contains columns with names containing accented characters would cause the data to be null (empty). (Bug#38304)

The innodb_log_arch_dir system variable is no longer available but was present in some of the sample option files included with MySQL distributions (such as my-huge.cnf). The line was present as a comment but uncommenting it would cause server startup failure so the line has been removed. (Bug#38249)

Errors during server startup caused destruction of an uninitialized mutex and assertion failure. (Bug#37961)

The handlerton-to-plugin mapping implementation did not free handler plugin references when the plugin was uninstalled, resulting in a server crash after several install/uninstall cycles. Also, on Mac OS X, the server crashed when trying to access an EXAMPLE table after the EXAMPLE plugin was installed. (Bug#37958)

The server crashed if an argument to a stored procedure was a subquery that returned more than one row. (Bug#37949)

When analyzing the possible index use cases, the server was incorrectly reusing an internal structure, leading to a server crash. (Bug#37943)

Access checks were skipped for SHOW PROCEDURE STATUS and SHOW FUNCTION STATUS, which could lead to a server crash or insufficient access checks in subsequent statements. (Bug#37908)

Comparisons could hang for SET or ENUM columns that used latin2_czech_cs collation. (Bug#37854)

It was possible to create a tasblespace using the name of one of the Falcon system tablespaces, FALCON_MASTER, FALCON_TEMPORARY, or FALCON_BACKLOG without an error message being raised. A suitable error is now produced when an attempt is made to create a table with the same name as a Falcon system tablespace. (Bug#37668)

SHOW PROCESSLIST displayed “copy to tmp table” when no such copy was occurring. (Bug#37550)

The <=> operator could return incorrect results when comparing NULL to DATE, TIME, or DATETIME values. (Bug#37526)

MySQL Backup was not consistently checking for BSTREAM_ERROR errors. (Bug#37522)

The combination of a subquery with a GROUP BY, an aggregate function calculated outside the subquery, and a GROUP BY on the outer SELECT could cause the server to crash. (Bug#37348)

Incorrect BLOB handling by RESTORE could result in a server crash. (Bug#37212)

The NO_BACKSLASH_ESCAPES SQL mode was ignored for LOAD DATA INFILE and SELECT INTO ... OUTFILE. The setting is taken into account now. (Bug#37114)

If thread-pooling was used and a connection attempt was denied on the grounds of exceeding the user limits, the number of active connections for that user was erroneously decreased twice. The difference between the actual number connections and the internal count could then cause debug builds of the server to raise an assertion. (Bug#36970)

Long error messages for RESTORE could be truncated. (Bug#36854)

Running in strict mode, with a auto_increment_increment and auto_increment_offset set to a value larger than supportedf by the specified auto increment column within a Falcon table, a crash would occur. (Bug#36473)

In some cases, references to views were confused with references to anonymous tables and privilege checking was not performed. (Bug#36086)

For crash reports on Windows, symbol names in stack traces were not correctly resolved. (Bug#35987)

ALTER EVENT changed the PRESERVE attribute of an event even when PRESERVE was not specified in the statement. (Bug#35981)

Host name values in SQL statements were not being checked for '@', which is illegal according to RFC952. (Bug#35924)

mysql_install_db failed on machines that had the host name set to localhost. (Bug#35754)

Dynamic plugins failed to load on i5/OS. (Bug#35743)

With the PAD_CHAR_TO_FULL_LENGTH SQL mode enabled, a ucs2 CHAR column returned additional garbage after trailing space characters. (Bug#35720)

RESTORE did not set the validity_point_time, binlog_pos, and binlog_file fields of the backup_history log table row. (Bug#35240)

With binary logging enabled, CREATE TABLE ... SELECT failed if the source table was a log table. (Bug#34306)

If BACKUP DATABASE and RESTORE were done in a session with autocommit disabled, a later DROP TABLE or RESTORE in the same session failed. (Bug#34204)

The secure_file_priv system variable now applies to BACKUP DATABASE and RESTORE operations: If the value is nonempty, backup and restore operations can read and write files only in the given directory. (Bug#34171)

mysql_real_connect() did not check whether the MYSQL connection handler was already connected and connected again even if so. Now an CR_ALREADY_CONNECTED error occurs. (Bug#33831)

Shutting down the MySQL Server immediately following the execution of a BACKUP DATABASE statement caused the server to crash if the database to be backed up contained any Falcon tables. (Bug#33575)

The server crashed for BACKUP DATABASE if the backup progress tables in the mysql database were missing or created incorrectly. (Bug#33352)

CHECKSUM TABLE was not killable with KILL QUERY. (Bug#33146)

A trigger for an InnoDB table activating multiple times could lead to AUTO_INCREMENT gaps. (Bug#31612)

mysqldump could fail to dump views containing a large number of columns. (Bug#31434)

The server could improperly type user-defined variables used in the select list of a query. (Bug#26020)

For access to the INFORMATION_SCHEMA.VIEWS table, the server did not check the SHOW VIEW and SELECT privileges, leading to inconsistency between output from that table and the SHOW CREATE VIEW statement. (Bug#22763)

mysqld_safe would sometimes fail to remove the pid file for the old mysql process after a crash. As a result, the server would fail to start due to a false A mysqld process already exists... error. (Bug#11122)

Important Change: mysqlbinlog now supports --verbose and --base64-output=DECODE-ROWS options to display row events as commented SQL statements. (The default otherwise is to display row events encoded as base-64 strings using BINLOG statements.) See Section 4.6.8.2, “mysqlbinlog Row Event Display”. (Bug#31455)

Falcon builds on AMD64 platforms now. (Bug#38535)

mysqltest now installs signal handlers and generates a stack trace if it crashes. (Bug#37003)

A new system variable, backupdir, enables the default directory to be specified for BACKUP DATABASE and RESTORE operations when the image file path name is not a full path name. The default value for this variable is the data directory. (Bug#35230)

The mysql.online_backup and mysql.online_backup_progress tables now have a default character set of utf8 rather than latin1. (Bug#33836)

mysqltest was changed to be more robust in the case of a race condition that can occur for rapid disconnect/connect sequences with the server. The account used by mysqltest could reach its allowed simultaneous-sessions user limit if the connect attempt occurred before the server had fully processed the preceding disconnect. mysqltest now checks specificaly for a user-limits error when it connects; if that error occurs, it delays briefly before retrying. (Bug#23921)

Previously, BACKUP DATABASE did not back up privileges and RESTORE did not restore them. Now privileges for backed-up databases are saved. This includes privileges at the database level and below (table, column, routine). Global privileges are not saved. For additional information about how privileges are backed up, see Section 6.3.1, “Quick Guide to MySQL Backup”.

A new session system variable, backup_wait_timeout, controls the number of seconds a BACKUP DATABASE or RESTORE operation waits for a blocked DDL statements before aborting with an error.

The CREATE TABLESPACE privilege has been introduced. This privilege exists at the global (superuser) level and enables you to create, alter, and drop tablespaces and logfile groups.

Improvements made to MySQL Backup (the BACKUP DATABASE and RESTORE statements):

Security Enhancement: The server consumed excess memory while parsing statements with hundreds or thousands of nested boolean conditions (such as OR (OR ... (OR ... ))). This could lead to a server crash or incorrect statement execution, or cause other client statements to fail due to lack of memory. The latter result constitutes a denial of service. (Bug#38296)

Incompatible Change: There were some problems using DllMain() hook functions on Windows that automatically do global and per-thread initialization for libmysqld.dll:

To correct these problems, DLL initialization code now is not invoked from libmysql.dll by default. (Bug#37226, Bug#33031)

Incompatible Change: Some performance problems of SHOW ENGINE INNODB STATUS were reduced by removing used cells and Total number of lock structs in row lock hash table from the output. Now these values are present only if the UNIV_DEBUG symbol is defined at MySQL build time. (Bug#36941, Bug#36942)

Important Change: The INFORMATION_SCHEMA.FALCON_TABLES table has been removed. (Bug#29211, Bug#34705, Bug#34706)

Partitioning: When a partitioned table had a TIMESTAMP column defined with CURRENT_TIMESTAMP as the default but with no ON UPDATE clause, the column's value was incorrectly set to CURRENT_TIMESTAMP when updating across partitions. (Bug#38272)

Partitioning: A LIST partitioned MyISAM table returned erroneous results when an index was present on a column in the WHERE clause and NOT IN was used on that column.

Searches using the index were also much slower then if the index were not present. (Bug#35931)

Partitioning: SELECT COUNT(*) was not correct for some partitioned tables using a storage engine that did not support HA_STATS_RECORDS_IS_EXACT. Tables using the ARCHIVE storage engine were known to be affected.

This was because ha_partition::records() was not implemented, and so the default handler::records() was used in its place. However, this is not correct behavior if the storage engine does not support HA_STATS_RECORDS_IS_EXACT.

The solution was to implement ha_partition::records() as a wrapper around the underlying partition records.

As a result of this fix, the rows column in the output of EXPLAIN PARTITIONS now includes the total number of records in the partitioned table. (Bug#35745)

Replication: Server code used in binary logging could in some cases be invoked even though binary logging was not actually enabled, leading to asserts and other server errors. (Bug#38798)

Replication: Row-based replication broke for utf8 CHAR columns longer than 85 characters. (Bug#37426)

Replication: When autocommit was set equal to 1 after starting a transaction, the binary log did not commit the outstanding transaction. The reason this happened was that the binary log commit function saw only the values of the new settings, and decided that there was nothing to commit.

This issue was first observed when using the Falcon storage engine, but it is possible that it affected other storage engines as well. (Bug#37221)

Replication: Some kinds of internal errors, such as Out of memory errors, could cause the server to crash when replicating statements with user variables.

certain internal errors. (Bug#37150)

Replication: Row-based replication did not correctly copy TIMESTAMP values from a big-endian storage engine to a little-endian storage engine. (Bug#37076)

Replication: The --replicate-*-table options were not evaluated correctly when replicating multi-table updates.

As a result of this fix, replication of multi-table updates no longer fails when an update references a missing table but does not update any of its columns. (Bug#37051)

Replication: Performing an insert on a table having an AUTO_INCREMENT column and an INSERT trigger that was being replicated from a master running MySQL 5.0 or any version of MySQL 5.1 up to and including MySQL 5.1.11 to a slave running MySQL 5.1.12 or later caused the replication slave to crash. (Bug#36443)

See also Bug#33029.

Multiple concurrent inserts to a Maria table could lead to a deadlock situation. (Bug#39363)

When renaming a Falcon table the corresponding indexes could become corrupt or unavailable. (Bug#39354)

When performing an online DROP INDEX on a Falcon table, the operation may conflict with other index operations such as including index scans. When one client drops an index, another client may initiate a concurrent index operation that accesses the mapping object of the index being dropped, and this can cause a crash. (Bug#39349, Bug#39350, Bug#39845, Bug#39846)

Explicitly running an online index operation on a Falcon table using ALTER ONLINE TABLE ... would fail with an error specifying that the specified operation was not supported. (Bug#39347)

Running LOAD DATA INFILE on a large source data into a Falcon table with millions of rows, a crash could occur. (Bug#39296)

Compiling Falcon on Solaris SPARC or x86 using the Sun Studio 12 compiler would lead to exceptions being disabled. Exceptions are required by Falcon and the build and binary would ultimately fail during execution. (Bug#39241)

Host name lookup failure could lead to a server crash. (Bug#39153)

When recovering from a serial log containing many CREATE TABLESPACE and DROP TABLESPACE statements, Falcon could lose data from tablespaces not referenced by these statements. (Bug#39138)

See also Bug#39789.

When specifying an alternative log directory for FALCON using serial_log_directory the operation would fail silently if the directory did not exist. MySQL will now fail to start if the serial log in the specified directory cannot be opened or created, or if the falcon_master.fts cannot be opened or created. (Bug#39098, Bug#38377)

Falcon key pages were written to the serial log in the wrong order. This had the potential to cause problems if a failure of the server occurred during recovery. (Bug#39025)

Falcon could hang trying to perform an UPDATE in one transaction while waiting for another transaction to be committed or rolled back. (Bug#38947)

It was not possible to build the server with Falcon support on SPARC when using the Sun Studio compiler. (Bug#38891)

On Solaris platforms, when the server was built with Falcon support and the data directory set in user's home directory, mysql_install_db failed. (Bug#38843)

Falcon did not honor the --datadir option and created its files in the current directory instead. This error was apparent only when running the embedded version of MySQL. (Bug#38770)

When built with Falcon support on 64-bit SPARC platforms, mysqld hung on startup. This occurred whether Sun Studio or gcc was used to compile the server. (Bug#38766)

Falcon did not build on Linux with Valgrind enabled. (Bug#38746)

Performing a DELETE on a Maria table where the table has been locked using LOCK TABLE ... WRITE CONCURRENT would result in an assertion failure. (Bug#38606)

When using mysql_install_db on MySQL built with Sun Studio 12 with the --with-debug option enabled, the server would crash. (Bug#38594)

Server-side cursors were not initialized properly, which could cause a server crash. (Bug#38486)

A server crash or Valgrind warnings could result when a stored procedure selected from a view that referenced a function. (Bug#38291)

A failure to clean up binary log events was corrected (detected by Valgrind). (Bug#38290)

Queries containing a subquery with DISTINCT and ORDER BY could cause a server crash. (Bug#38191)

CREATE TABLESPACE failed when invoked immediately following a DROP TABLESPACE statement that used the same tablespace name. (Bug#38186, Bug#38743)

Over-aggressive lock acquisition by InnoDB when calculating free space for tablespaces could result in performance degradation when multiple threads were executing statements on multi-core machines. (Bug#38185)

The fix for Bug#20748 caused a problem such that on Unix, MySQL programs looked for options in ~/my.cnf rather than the standard location of ~/.my.cnf. (Bug#38180)

UUID() values could have hyphens in the wrong place. (Bug#38160)

Queries with a HAVING clause could return a spurious row. (Bug#38072)

MyISAM tables with non-ASCII characters in their names could not be backed up because the MyISAM native backup driver did not handle them properly. (Bug#38045)

Dropping and re-creating a Falcon table, then adding indexes to the re-created table, could cause spurious errors or possibly a crash of the server. (Bug#38039)

If the table definition cache contained tables with many BLOB columns, much memory could be allocated to caching BLOB values. Now a size limit on the cached BLOB values is enforced. (Bug#38002)

The server returned incorrect results for WHERE ... OR ... GROUP BY queries against InnoDB tables. (Bug#37977)

SUM(DISTINCT) and AVG(DISTINCT) for an empty result set in a subquery were not properly handled as being able to return NULL. (Bug#37891)

For InnoDB tables, ORDER BY ... DESC sometimes returned results in ascending order. (Bug#37830)

The server returned unexpected results if a right side of the NOT IN clause consisted of the NULL value and some constants of the same type. For example, this query might return 3, 4, 5, and so forth if a table contained those values:

SELECT * FROM t WHERE NOT t.id IN (NULL, 1, 2);

(Bug#37761)

Executing large numbers of SQL statements using LIMIT on Falcon tables eventually led to a crash of the server. (Bug#37726)

Setting the session value of the innodb_table_locks system variable caused a server crash. (Bug#37669)

Nesting of IF() inside of SUM() could cause an extreme server slowdown. (Bug#37662)

For BACKUP DATABASE, if the WITH COMPRESSION clause was not used, an uninitialized variable could cause unpredictable results. (Bug#37654)

Killing a query that used an EXISTS subquery as the argument to SUM() or AVG() caused a server crash. (Bug#37627)

mysqld failed to build using the Sun Studio compiler. (Bug#37603)

When using indexed ORDER BY sorting, incorrect query results could be produced if the optimizer switched from a covering index to a noncovering index. (Bug#37548)

After TRUNCATE TABLE for an InnoDB table, inserting explicit values into an AUTO_INCREMENT column could fail to increment the counter and result in a duplicate-key error for subsequent insertion of NULL. (Bug#37531)

For a MyISAM table with CHECKSUM = 1 and ROW_FORMAT = DYNAMIC table options, a data consistency check (maximum record length) could fail and cause the table to be marked as corrupted. (Bug#37310)

The max_length result set metadata value was calculated incorrectly under some circumstances. (Bug#37301)

The optimizer_switch system variable takes a comma-separated list of values, but only the first value in the list was used. (Bug#37120)

Executing ALTER TABLE ADD PARTITION followed by ALTER TABLE DROP PARTITION on a Falcon table, and then killing the thread performing these statements could cause the server to crash. (Bug#37072)

NOT IN subqueries that selected MIN() or MAX() values but produced an empty result could cause a server crash. (Bug#37004)

A server crash resulted from attempts at semi-join and materialization optimizations for subqueries with a parent of SELECT ... FROM DUAL. (Bug#36896)

Server crashed when starting a new BACKUP DATABASE or RESTORE statement while a BACKUP DATABASE or RESTORE was ongoing. (Bug#36795)

The CSV storage engine returned success even when it failed to open a table's data file. (Bug#36638)

SELECT DISTINCT from a simple view on an InnoDB table, where all selected columns belong to the same unique index key, returned incorrect results. (Bug#36632)

RESTORE could fail if the server on which the restore operation took place had enabled triggers or events. (Bug#36530)

The parser incorrectly allowed MySQL error code 0 to be specified for a condition handler. (This is incorrect because the condition must be a failure condition and 0 indicates success.) (Bug#36510)

CHAR(256 USING utf32) could generate a result with an incorrect length and result in a server crash. (Bug#36418)

If initialization of an INFORMATION_SCHEMA plugin failed, INSTALL PLUGIN freed some internal plugin data twice. (Bug#36399)

When the fractional part in a multiplication of DECIMAL values overflowed, the server truncated the first operand rather than the longest. Now the server truncates so as to produce more precise multiplications. (Bug#36270)

The server could crash with an assertion failure (or cause the client to get a “Packets out of order” error) when the expected query result was that it should terminate with a “Subquery returns more than 1 row” error. (Bug#36135)

Executing TRUNCATE statements with interleaving transactions could cause mysqld to crash. (Bug#35991)

See also Bug#22165.

When using both an INSERT BEFORE trigger to create a row and AFTER INSERT trigger to delete the same row on a FALCON table, the record count as reported by SHOW TABLE STATUS could get out of sync with the actual record contents. This was caused by the changes now being correctly updated in the table status information. (Bug#35939)

Multiple threads executing repeated queries on the same Falcon table led eventually to a crash of the server. (Bug#35932, Bug#36410)

The UUID() function returned UUIDs with the wrong time; this was because the offset for the time part in UUIDs was miscalculated. (Bug#35848)

The configure script did not allow utf8_hungarian_ci to be specified as the default collation. (Bug#35808)

For CREATE TABLE, the parser did not enforce that parentheses were present in a CHECK (expr) clause; now it does. The parser did not enforce that CONSTRAINT [symbol] without a following CHECK clause was illegal; now it does. (Bug#35578, Bug#11714, Bug#38696)

Freeing of an internal parser stack during parsing of complex stored programs caused a server crash. (Bug#35577, Bug#37269, Bug#37228)

mysqlbinlog left temporary files on the disk after shutdown, leading to the pollution of the temporary directory, which eventually caused mysqlbinlog to fail. This caused problems in testing and other situations where mysqlbinlog might be invoked many times in a relatively short period of time. (Bug#35543)

The code for detecting a byte order mark (BOM) caused mysql to crash for empty input. (Bug#35480)

Index scans performed with the sort_union() access method returned wrong results, caused memory to be leaked, and caused temporary files to be deleted when the limit set by sort_buffer_size was reached. (Bug#35477, Bug#35478)

For uncorrelated subqueries without a WHERE clause, use of semi-join or materialization options could result in slow performance, or use of the LooseScan strategy could produce incorrect results. (Bug#35468)

CSV tables with CHAR columns caused BACKUP DATABASE to produce a server crash. (Bug#35117)

If a view depended on a base table that had been dropped, BACKUP DATABASE caused a server crash. (Bug#34902)

If a view was altered before backing up a database, BACKUP DATABASE caused a server crash. (Bug#34867)

Table checksum calculation could cause a server crash for FEDERATED tables with BLOB columns containing NULL values. (Bug#34779)

BACKUP DATABASE caused a server crash if it attempted to back up a view that depended on another view. (Bug#34758, Bug#35347)

A significant slowdown occurred when many SELECT statements that return many rows from InnoDB tables were running concurrently. (Bug#34409)

mysql_install_db failed if the server was running with an SQL mode of TRADITIONAL. This program now resets the SQL mode internally to avoid this problem. (Bug#34159)

Changes to build files were made to enable the MySQL distribution to compile on Microsoft Visual C++ Express 2008. (Bug#33907)

Fast ALTER TABLE operations were not fast for columns that used multibyte character sets. (Bug#33873)

ORDER BY failed to take into account accents and lettercases in multi-level collations (latin2_czech_cs and cp1250_czech_cs). (Bug#33791, Bug#30462)

The internal functions my_getsystime(), my_micro_time(), and my_micro_time_and_time() did not work correctly on Windows. One symptom was that uniqueness of UUID() values could be compromised. (Bug#33748)

The SHOW FUNCTION CODE and SHOW PROCEDURE CODE statements are not present in nondebug builds, but attempting to use them resulted in a “syntax error” message. Now the error message indicates that the statements are disabled and that you must use a debug build. (Bug#33637)

If a large number of databases were named in the BACKUP DATABASE statement, the server crashed. (Bug#33568)

Cached queries that used 256 or more tables were not properly cached, so that later query invalidation due to a TRUNCATE TABLE for one of the tables caused the server to hang. (Bug#33362)

BACKUP DATABASE did not properly set the flags in the first two bytes of the backup image. (Bug#33120)

Unindexed ORDER BY did not work on short utf32 columns, or on utf16 columns with a short max_sort_length value. (Bug#33073)

BACKUP DATABASE followed by RESTORE could mangle object names if a nonstandard charset was used. (Bug#33023)

After an upgrade to MySQL 6.0.4 or higher, columns that used the old 3-byte Unicode utf8 character set are treated as having the utf8mb3 character set. mysql_upgrade did not convert all system tables in the mysql database to use the new 4-byte Unicode utf8 character set rather than utf8mb3. This caused problems such as that the event scheduler would not start. mysql_upgrade now performs the utf8mb3 to utf8 conversion for system tables. (Bug#33002, Bug#33053)

It was possible to insert invalid Unicode characters (with code point values greater than U+10FFFF) into utf8 and utf32 columns. (Bug#32914)

UNION constructs cannot contain SELECT ... INTO except in the final SELECT. However, if a UNION was used in a subquery and an INTO clause appeared in the top-level query, the parser interpreted it as having appeared in the UNION and raised an error. (Bug#32858)

Inserting CURRENT_TIME, CURRENT_DATE, or CURRENT_TIMESTAMP into a VARCHAR column didn't work for non-ASCII character sets such as ucs2, utf16, or utf32. (Bug#32390)

mysql_upgrade attempted to use the /proc file system even on systems that do not have it. (Bug#31605)

mysql_install_db failed if run with the default table type set to NDB. (Bug#31315)

Making INFORMATION_SCHEMA the default database caused the DROP TABLESPACE statement to be disabled. (Bug#31302)

Several MySQL programs could fail if the HOME environment variable had an empty value. (Bug#30394)

The Serbian translation for the ER_INCORRECT_GLOBAL_LOCAL_VAR error was corrected. (Bug#29738)

The BUILD/check-cpu build script failed if gcc had a different name (such as gcc.real on Debian). (Bug#27526)

ALTER TABLE could not be used to add columns to a table if the table had an index on a utf8 column with a TEXT data type. (Bug#26180)

The XPath boolean() function did not cast string and nodeset values correctly in some cases. It now returns TRUE for any nonempty string or nodeset and 0 for a NULL string, as specified in the XPath standard.. (Bug#26051)

Using ALTER TABLE with interleaving transactions could cause mysqld to crash. (Bug#22165)

The FLUSH PRIVILEGES statement did not produce an error when it failed. (Bug#21226)

After executing a prepared statement that accesses a stored function, the next execution would fail to find the function if the stored function cache was flushed in the meantime. (Bug#12093, Bug#21294)

perror did not work for errors described in the sql/share/errmsg.txt file. (Bug#10143)

Important Change: Incompatible Change: The FEDERATED storage engine is now disabled by default in binary distributions. The engine is still available and can be enabled by starting the server with the --federated option. (Bug#37069)

Incompatible Change: The engines column in the mysql.online_backup table has been renamed to drivers to better reflect its contents. (Bug#34965)

Incompatible Change: A change has been made to the way that the server handles prepared statements. This affects prepared statements processed at the SQL level (using the PREPARE statement) and those processed using the binary client-server protocol (using the mysql_stmt_prepare() C API function).

Previously, changes to metadata of tables or views referred to in a prepared statement could cause a server crash when the statement was next executed, or perhaps an error at execute time with a crash occurring later. For example, this could happen after dropping a table and recreating it with a different definition.

Now metadata changes to tables or views referred to by prepared statements are detected and cause automatic repreparation of the statement when it is next executed. Metadata changes occur for DDL statements such as those that create, drop, alter, rename, or truncate tables, or that analyze, optimize, or repair tables. Repreparation also occurs after referenced tables or views are flushed from the table definition cache, either implicitly to make room for new entries in the cache, or explicitly due to FLUSH TABLES.

Repreparation is automatic, but to the extent that it occurs, performance of prepared statements is diminished.

Table content changes (for example, with INSERT or UPDATE) do not cause repreparation, nor do SELECT statements.

An incompatibility with previous versions of MySQL is that a prepared statement may now return a different set of columns or different column types from one execution to the next. For example, if the prepared statement is SELECT * FROM t1, altering t1 to contain a different number of columns causes the next execution to return a number of columns different from the previous execution.

Older versions of the client library cannot handle this change in behavior. For applications that use prepared statements with the new server, an upgrade to the new client library is strongly recommended.

Along with this change to statement repreparation, the default value of the table_definition_cache system variable has been increased from 128 to 256. The purpose of this increase is to lessen the chance that prepared statements will need repreparation due to referred-to tables/views having been flushed from the cache to make room for new entries.

A new status variable, Com_stmt_reprepare, has been introduced to track the number of repreparations. (Bug#27420, Bug#27430, Bug#27690)

Important Change: Some changes were made to CHECK TABLE ... FOR UPGRADE and REPAIR TABLE with respect to detection and handling of tables with incompatible .frm files (files created with a different version of the MySQL server). These changes also affect mysqlcheck because that program uses CHECK TABLE and REPAIR TABLE, and thus also mysql_upgrade because that program invokes mysqlcheck.

(Bug#36055)

Important Change: The Maria Storage Engine is now available as standard. Maria is a crash safe version of MyISAM. Maria supports all of the main functionality of the MyISAM engine, but includes recovery support (in the event of a system crash), full logging (including CREATE, DROP, RENAME, and TRUNCATE operations), all MyISAM row formats and a new Maria-specific row format. Maria is documented at Section 13.6, “The Maria Storage Engine”.

Important Note: When MySQL is built with the Maria engine, all internal temporary on disk tables will use the Maria engine. Using Maria temporary tables in plkace of MyISAM tables should result in a performance gain.

On Unix, it is now possible for the output file for BACKUP DATABASE to be an existing FIFO. (Bug#37012)

mysql_upgrade now has a --tmpdir option to enable the location of temporary files to be specified. (Bug#36469)

mysqldump now adds the LOCAL qualifier to the FLUSH TABLES statement that is sent to the server when the --master-data option is enabled. This prevents the FLUSH TABLES statement from replicating to slaves, which is disadvantageous because it would cause slaves to block while the statement executes. (Bug#35157)

See also Bug#38303.

The use of the SQL_CACHE and SQL_NO_CACHE options in SELECT statements now is checked more restrictively: 1) Previously, both options could be given in the same statement. This is no longer true; only one can be given. 2) Previously, these options could be given in SELECT statements that were not at the top-level. This is no longer true; the options are disallowed in subqueries (including subqueries in the FROM clause, and SELECT statements in unions other than the first SELECT. (Bug#35020)

MySQL source distributions are now available in Zip format. (Bug#27742)

The undocumented, deprecated, and not useful SHOW COLUMN TYPES statement has been removed. (Bug#5299)

The server now supports a Debug Sync facility for thread synchronization during testing and debugging. To compile in this facility, configure MySQL with the --enable-debug-sync option. The debug_sync system variable provides the user interface Debug Sync. mysqld and mysql-test-run.pl support a --debug-sync-timeout option to enable the facility and set the default synchronization point timeout.

mysql-test-run.pl now supports a --mysqltest option for specifying options to the mysqltest program.

Several improvements were made to MySQL Backup (the BACKUP DATABASE and RESTORE statements):

BACKUP DATABASE now has a WITH COMPRESSION clause. This causes the image file to be compressed, which reduces its size. Compression also may result in improved backup time by reducing writes to disk.

When reading from FALCON tables, FALCON can take advantage of reading from the disk in larger blocks. When enabled, disk reads are in blocks of 64KB. When switched off, disk reads are based on the page size as set by falcon_page_size.

Important Change: Security Fix: Additional corrections were made for the symlink-related privilege problem originally addressed in MySQL 6.0.5. The original fix did not correctly handle the data directory path name if it contained symlinked directories in its path, and the check was made only at table-creation time, not at table-opening time later. (Bug#32167, CVE-2008-2079)

See also Bug#39277.

Incompatible Change: SHOW STATUS took a lot of CPU time for calculating the value of the Innodb_buffer_pool_pages_latched status variable. Now this variable is calculated and included in the output of SHOW STATUS only if the UNIV_DEBUG symbol is defined at MySQL build time. (Bug#36600)

Incompatible Change: Access privileges for several statements are more accurately checked:

(Bug#27145)

Incompatible Change: Certain characters were sorted incorrectly for the following collations: TILDE and GRAVE ACCENT in big5_chinese_ci; LATIN SMALL LETTER J in cp866_general_ci; TILDE in gb2312_chinese_ci; and TILDE in gbk_chinese_ci.

As a result of this fix, any indexes on columns that use these collations and contain the affected characters must be rebuilt when upgrading to 6.0.6 or higher. To do this, use ALTER TABLE to drop and re-add the indexes, or mysqldump to dump the affected tables and mysql to reload the dump file. (Bug#25420)

Incompatible Change: An additional correction to the original MySQL 6.0.4 fix was made to normalize directory names before adding them to the list of directories. This prevents /etc/ and /etc from being considered different, for example. (Bug#20748)

See also Bug#38180.

Important Change: Previously, Falcon failed silently when attempting to read incompatible datafiles created by an earlier version of the storage engine. Now, when Falcon encounters such datafiles, it refuses to start, and an appropriate error is issued instead. (Bug#35190)

Important Change: The server no longer issues warnings for truncation of excess spaces for values inserted into CHAR columns. This reverts a change in the previous release that caused warnings to be issued. (Bug#30059)

Partitioning: Important Note: The statements ANALYZE TABLE, CHECK TABLE, OPTIMIZE TABLE, and REPAIR TABLE are now supported for partitioned tables.

Also as a result of this fix, the following statements which were disabled in MySQL 6.0.5 have been re-enabled:

(Bug#20129)

See also Bug#39434.

Partitioning: myisamchk failed with an assertion error when analyzing a partitioned MyISAM table. (Bug#37537)

Partitioning: When an attempt is made to change a table to an unsupported storage engine, the server normally uses the default storage engine in place of the requested engine while issuing a warning. However, if the table was partitioned, the same ALTER TABLE statement failed with the error, The mix of handlers in the partitions is not allowed in this version of MySQL. This happened even if the server was not running in NO_ENGINE_SUBSTITUTION mode. Now the behavior for partitioned tables is the same as for other MySQL tables; the substitution is made, and a warning is issued. (Bug#35765)

Partitioning: MyISAM recovery enabled with the --myisam-recover option did not work for partitioned MyISAM tables. (Bug#35161)

Partitioning: When one user was in the midst of a transaction on a partitioned table, a second user performing an ALTER TABLE on this table caused the server to hang. (Bug#34604)

Partitioning: Inserts failed on partitioned tables containing user-supplied values for an AUTO_INCREMENT column. (Bug#33479)

Partitioning: Partition-level TABLESPACE options were ignored for Falcon tables. (Bug#33404)

Partitioning: For InnoDB tables, there was a race condition involving the data dictionary and repartitioning. (Bug#33349)

Replication: CREATE PROCEDURE and CREATE FUNCTION statements containing extended comments were not written to the binary log correctly, causing parse errors on the slave. (Bug#36570)

See also Bug#32575.

Replication: When flushing tables, there was a slight chance that the flush occurred between the processing of one table map event and the next. Since the tables were opened one by one, subsequent locking of tables would cause the slave to crash. This problem was observed when replicating NDBCLUSTER or InnoDB tables, when executing multi-table updates, and when a trigger or a stored routine performed an (additional) insert on a table so that two tables were effectively being inserted into in the same statement. (Bug#36197)

Replication: INSTALL PLUGIN and UNINSTALL PLUGIN caused row-based replication to fail.

(Bug#35807)

Replication: CREATE VIEW statements containing extended comments were not written to the binary log correctly, causing parse errors on the slave. Now, all comments are stripped from such statements before being written to the binary log. (Bug#32575)

See also Bug#36570.

The minimum page size accepted by FALCON has been increased from 1K to 2K. (Bug#39707)

Trying to execute a DDL statement on a Falcon table while a transaction was being rolled back could cause the server to crash. (Bug#38933)

When building FALCON using the Sun Studio 12 compiler, a requirement for the GNU Standard C++ (libstdc++) library would be added to the build requirements, causing the build to fail. (Bug#38556)

The Falcon memory manager did not always perform initialization of internal objects correctly. (Bug#38519)

See also Bug#38770.

Disconnecting a session where you have a applied a WRITE CONCURRENT lock on Maria tables would lead to a crash. (Bug#38492)

Range queries on a Maria table could fail to return the correct rows. (Bug#38466)

The Windows my-template.ini template file contained a reference to the myisam_max_extra_sort_file_size system variable, which no longer exists, causing the installed server to fail upon startup. (Bug#38371)

Incorrect handling of aggregate functions when loose index scan was used caused a server crash. (Bug#38195)

The fix for Bug#33812 had the side effect of causing the mysql client not to be able to read some dump files produced with mysqldump. To address this, that fix was reverted. (Bug#38158)

The MyISAM backup driver was subject to a race condition that allowed multiple RESTORE operations to occur simultaneously. This could result in locking conflicts, incorrect entries in the progress tables, or other problems. (Bug#38108)

Concurrent adding or dropping of indexes and execution of DML statements on a Falcon table could cause the server to crash. (Bug#38044)

Executing ALTER TABLE and DML statements concurrently on Falcon tables could cause the server to hang. (Bug#38043)

ALTER TABLE ... ADD KEY and ALTER TABLE ... DROP KEY were not always handled correctly for Falcon tables, resulting in spurious duplicate key and other errors. (Bug#38041)

If a table has a BIT NOT NULL column c1 with a length shorter than 8 bits and some additional NOT NULL columns c2, ..., and a SELECT query has a WHERE clause of the form (c1 = constant) AND c2 ..., the query could return an unexpected result set. (Bug#37799)

MySQL server binaries built using gcc4.3 could crash when running large numbers of DML statements on Falcon tables. (Bug#37725)

When building FALCON using the Sun Studio 12 compiler on OpenSolaris the build would fail due to a missing header file, Interlock.h. (Bug#37679)

Building MySQL with SSL and Falcon enabled would lead to a build failure. (Bug#37517)

A large number of updates on a Falcon table followed by a query of the form SELECT AVG(int_non_key_column) FROM table WHERE int_non_key_column < constant GROUP BY int_key_column LIMIT limit could crash the server. (Bug#37344)

Queries with complex conditions in the WHERE clause on Falcon tables when falcon_page_size was set to a low value could cause the server to crash. (Bug#37343)

Within stored programs or prepared statements, REGEXP could return incorrect results due to improper initialization. (Bug#37337)

When running a concurrent scenario involving transactions, each executing a small number of DELETE and UPDATE operations on a small number of records on FALCON tables, a deadlock could occur. (Bug#37251)

When performing operations on a table in one client while a different client is performing a TRUNCATE operation on the same FALCON table a deadlock could be introduced. (Bug#37080)

The falcon_max_transaction_backlog has been removed. The option was originally introduced to ensure that the backlog of transactions did not exceed a certain level with the gopher thread. FALCON now uses multiple gopher threads. The transaction backlog is handled internally by FALCON. (Bug#36991)

The falcon_initial_allocation has been removed. The option created new tablespace files with the specified size to force allocation on disk of specified block of contiguous space. The option had little effect on the performance of the tablespace files, and has therefore been removed. (Bug#36990)

The falcon_index_chill_threshold and falcon_record_chill_threshold options have been modified so that the specification for the size can be specified in bytes, and support the KB, MB, and GB modifiers. (Bug#36825)

The code for the ut_usectime() function in InnoDB did not handle errors from the gettimeofday() system call. Now it retries gettimeofday() several times and updates the value of the Innodb_row_lock_time_max status variable only if ut_usectime() was successful. (Bug#36819)

If the length of a field was 3, internal InnoDB to integer type conversion didn't work on big-endian machines in the row_search_autoinc_column() function. (Bug#36793)

For a view that referred to a MyISAM table, the contents of the table could be empty after BACKUP DATABASE followed by RESTORE. (Bug#36782)

Data loss could be caused by attempts to read data from a database being restored by a RESTORE operation. (Bug#36778)

Some warnings were being reported as errors. (Bug#36777)

Data loss could be caused by activation of a trigger for a MyISAM table being restored by a RESTORE operation. (Bug#36749)

mysql_install_db from a Falcon-enabled build crashed on Solaris/SPARC. (Bug#36745)

On Windows 64-bit systems, temporary variables of long types were used to store ulong values, causing key cache initialization to receive distorted parameters. The effect was that setting key_buffer_size to values of 2GB or more caused memory exhaustion to due allocation of too much memory. (Bug#36705)

Multiple-table UPDATE statements that used a temporary table could fail to update all qualifying rows or fail with a spurious duplicate-key error. (Bug#36676)

A query which had an ORDER BY DESC clause that is satisfied with a reverse range scan could cause a server crash for some specific CPU/compiler combinations. (Bug#36639)

The online backup stream library failed to parse the backup stream on 64-bit systems. (Bug#36624)

FALCON would try to open a number of files during startup that are not required by the MySQL storage engine implmentation. These operations have been removed. (Bug#36620)

On 64-bit platforms, BACKUP DATABASE hung for backups of more than 32KB. (Bug#36586)

Dumping information about locks in use by sending a SIGHUP signal to the server or by invoking the mysqladmin debug command could lead to a server crash in debug builds or to undefined behavior in production builds. (Bug#36579)

A REGEXP match could return incorrect rows when the previous row matched the expression and used CONCAT() with an empty string. (Bug#36488)

The server could not be compiled with Falcon support on Solaris/x86. (Bug#36486)

mysqltest ignored the value of --tmpdir in one place. (Bug#36465)

The ER_TRUNCATED_WRONG_VALUE warning condition was sometimes raised as an error. (Bug#36457)

When one MySQL client application committed a transaction affecting a Falcon table at the same time that another client dropped this table, the DROP TABLE statement did not “see” that transaction. This led to a situation such that a row affected by the transaction was later accessed in a manner that referred to the deleted table, resulting in a crash of the server. (Bug#36438)

ha_innodb.so was incorrectly installed in the lib/mysql directory rather than in lib/mysql/plugin. (Bug#36434)

Compiling the server with Falcon support failed on Solaris 10 due to problems with DTrace. This occurred even when the build was configured using --disable-dtrace. (Bug#36403)

Compiling the server with Falcon support failed on Solaris 10 for x86 platforms failed due to use of assembler code specific to gcc. (Bug#36400)

Dropping a Falcon tablespace concurrently with dropping a table using that tablespace caused the server to crash. (Bug#36396)

Attempting to compile the server with Falcon support using the Sun Studio 12 compiler failed with the error "Value.h", line 185: Error: A union member cannot have a user-defined assignment operator. (Bug#36368)

The default drivers for BACKUP DATABASE and RESTORE now support a cancel operation, which also allows better cleanup if a driver error occurs. (Bug#36323)

The server crashed while parsing large floating-point numbers such as 1e37 or -1e15. (Bug#36320)

When updating an existing instance (for example, from MySQL 5.0 to 5.1, or 5.1 to 6.0), the Instance Configuration Wizard unnecessarily prompted for a root password when there was an existing root password. (Bug#36305)

Following a number of INSERT ... SELECT statements on a Falcon table, creating a second Falcon table using the same tablespace as the table into which the inserts were made and then performing a simple INSERT on the new table caused the server to crash. (Bug#36294, Bug#36367)

See also Bug#29648.

For InnoDB tables, the DATA_FREE column of the INFORMATION_SCHEMA.TABLES displayed free space in kilobytes rather than bytes. Now it displays bytes. (Bug#36278)

BACKUP DATABASE failed to back up views that depend on tables in a different database. (Bug#36265)

The project files created for Windows were missing the GenError project dependency. (Bug#36257)

The mysql client failed to recognize comment lines consisting of -- followed by a newline. (Bug#36244)

CREATE INDEX for InnoDB tables could under very rare circumstances cause the server to crash.. (Bug#36169)

A read past the end of the string could occur while parsing the value of the --innodb-data-file-path option. (Bug#36149)

Conversion of a FLOAT ZEROFILL value to string could cause a server crash if the value was NULL. (Bug#36139)

The combination of semi-join and materialization both being enabled could lead to assertion failure during subquery processing. (Bug#36137)

Range optimizer evaluation of IN subqueries to be handled with the materialization strategy could lead to assertion failure. (Bug#36133)

A server crash could occur during the cleanup phase of subquery execution. (Bug#36128)

On Windows, the installer attempted to use JScript to determine whether the target data directory already existed. On Windows Vista x64, this resulted in an error because the installer was attempting to run the JScript in a 32-bit engine, which wasn't registered on Vista. The installer no longer uses JScript but instead relies on a native WiX command. (Bug#36103)

A SELECT ... LIKE query issued following a number of INSERT statements on a Falcon table failed to return all matching records. (Bug#36097)

mysqltest was performing escape processing for the --replace_result command, which it should not have been. (Bug#36041)

An error in calculation of the precision of zero-length items (such as NULL) caused a server crash for queries that employed temporary tables. (Bug#36023)

For EXPLAIN EXTENDED, execution of an uncorrelated IN subquery caused a crash if the subquery required a temporary table for its execution. (Bug#36011)

The MERGE storage engine did a table scan for SELECT COUNT(*) statements when it could calculate the number of records from the underlying tables. (Bug#36006)

The server crashed inside NOT IN subqueries with an impossible WHERE or HAVING clause, such as NOT IN (SELECT ... FROM t1, t2, ... WHERE 0). (Bug#36005)

mysql_stmt_prepare() did not reset the list of messages (those messages available via SHOW WARNINGS). (Bug#36004)

The Event Scheduler was not designed to work under the embedded server. It is now disabled for the embedded server, and the event_scheduler system variable is not displayed. (Bug#35997)

Grouping or ordering of long values in unindexed BLOB or TEXT columns with the gbk or big5 character set crashed the server. (Bug#35993)

SET GLOBAL debug='' resulted in a Valgrind warning in DbugParse(), which was reading beyond the end of the control string. (Bug#35986)

If a SELECT table list contained at least one INFORMATION_SCHEMA table, the required privileges for accessing the other tables were reduced. (Bug#35955)

Some syntactically invalid statements could cause the server to return an error message containing garbage characters. (Bug#35936)

MySQL could not be built using Sun Studio due to the use of compiler options specific to gcc. (Bug#35929)

The “prefer full scan on clustered primary key over full scan of any secondary key” optimizer rule introduced by Bug#26447 caused a performance regression for some queries, so it has been disabled. (Bug#35850)

The server ignored any covering index used for ref access of a table in a query with ORDER BY if this index was incompatible with the ORDER BY list and there was another covering index compatible with this list. As a result, suboptimal execution plans were chosen for some queries that used an ORDER BY clause. (Bug#35844)

mysql_upgrade did not properly update the mysql.event table. (Bug#35824)

The current system time (as returned by NOW() or synonyms) became constant after a RESTORE operation. (Bug#35806)

Processing of an uncorrelated subquery using semi-join could cause incorrect results or a server crash. (Bug#35767)

An incorrect error and message was produced for attempts to create a MyISAM table with an index (.MYI) file name that was already in use by some other MyISAM table that was open at the same time. For example, this might happen if you use the same value of the INDEX DIRECTORY table option for tables belonging to different databases. (Bug#35733)

Enabling the read_only system variable while autocommit mode was enabled caused SELECT statements for transactional storage engines to fail. (Bug#35732)

The range optimizer ignored conditions on inner tables in semi-join IN subqueries, causing the optimizer to miss good query execution plans. (Bug#35674)

An empty bit-string literal (b'') caused a server crash. Now the value is parsed as an empty bit value (which is treated as an empty string in string context or 0 in numeric context). (Bug#35658)

On 64-bit systems, assigning values of 2 ⁶³ – 1 or larger to key_buffer_size caused memory overruns. (Bug#35616)

For InnoDB tables, REPLACE statements used “traditional” style locking, regardless of the setting of innodb_autoinc_lock_mode. Now REPLACE works the same way as “simple inserts” instead of using the old locking algorithm. (REPLACE statements are treated in the same way as as INSERT statements.) (Bug#35602)

Different invocations of CHECKSUM TABLE could return different results for a table containing columns with spatial data types. (Bug#35570)

A semi-join subquery in the ON clause in the absence of a WHERE clause caused a server crash. (Bug#35550)

InnoDB was not updating the Handler_delete or Handler_update status variables. (Bug#35537)

The method for enumerating view dependencies could cause the server to deadlock. (Bug#35395)

If the server crashed with an InnoDB error due to unavailability of undo slots, errors could persist during rollback when the server was restarted: There are two UNDO slot caches (for INSERT and UPDATE). If all slots end up in one of the slot caches, a request for a slot from the other slot cache would fail. This can happen if the request is for an UPDATE slot and all slots are in the INSERT slot cache, or vice versa. (Bug#35352)

Simultaneous inserts and updates on an updateable view referencing a Falcon table could sometimes cause duplicate key errors. (Bug#35322)

The combination of GROUP_CONCAT(), DISTINCT, and LEFT JOIN could crash the server when the right table is empty. (Bug#35298)

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)

BACKUP DATABASE caused a server crash upon encountering a table row that has been marked for deletion but not removed. (Bug#35249)

For InnoDB tables, ALTER TABLE DROP failed if the name of the column to be dropped began with “foreign”. (Bug#35220)

The table pullout strategy was not reflected in EXPLAIN EXTENDED output if not all of the subquery tables were pulled out. (Bug#35160)

Access-denied messages for INFORMATION_SCHEMA incorrectly showed the name of the default database instead. (Bug#35096)

Passing an invalid parameter to CHAR() in an ORDER BY clause caused the server to hang. (Bug#34949)

Some binaries produced stack corruption messages due to being built with versions of bison older than 2.1. Builds are now created using bison 2.3. (Bug#34926)

Concurrent execution of FLUSH TABLES along with SHOW FUNCTION STATUS or SHOW PROCEDURE STATUS could cause a server crash. (Bug#34895)

Creating a new Falcon table using CREATE TABLE ... SELECT where the table uses a primary key, and rows contain duplicate keys, could lead to a table being created but not populated. Because the pending (bad) record was not committed, the table remains in a state that means it cannot be dropped or recreated. (Bug#34892)

The log_output system variable could be set to an illegal value. (Bug#34820)

A server crash or memory overrun could occur with a dependent subquery and joins. (Bug#34799)

An assertion could be raised when the dependencies on a transaction could not be released after a specified time when using FALCON tables. (Bug#34602)

InnoDB could crash if overflow occurred for an AUTO_INCREMENT column. (Bug#34335)

On Windows 64-bit builds, an apparent compiler bug caused memory overruns for code in innobase/mem/*. Removed optimizations so as not to trigger this problem. (Bug#34297)

Several additional configuration scripts in the BUILD directory now are included in source distributions. These may be useful for users who wish to build MySQL from source. (See Section 2.9.3, “Installing from the Development Source Tree”, for information about what they do.) (Bug#34291)

For InnoDB tables, loss of data resulted from performing inserts concurrently with a RESTORE operation. (Bug#34210)

In some cases, concurrent INSERT and DELETE statements on the same Falcon table could cause the server to crash, due to a failure to find a record that should have been in the table. (Bug#33933)

A number of problems in new subquery optimization code meant that MySQL could pick an incorrect query plan when using InsideOut and/or FirstMatch subquery optimizations, which in turn would cause wrong query results. (Bug#33743)

If CREATE TABLE or ALTER TABLE of a Falcon table failed, it was not possible to create another table in the same database having the same name unless the server was restarted. In some cases, subsequent CREATE TABLE statements could cause the server to crash. (Bug#33723)

Attempts to access a FEDERATED table using a nonexistent server did not reliably return a proper error. (Bug#33702)

It was possible for multiple mysqld instances to use the same Falcon tablespace and metadata files, which could lead to corruption of the tablespace files, metadata files, or both. (Bug#33607)

TIMESTAMP columns were restored to the current date and time (not their actual values) by a RESTORE operation. (Bug#33573)

Use of 61 nested subqueries caused a server crash. (Bug#33509)

An ALTER TABLE ... TABLESPACE statement referencing a nonexistant tablespace on a Falcon table failed with an inappropriate error message the first time it was executed. A second attempt to execute the statement led to a crash of the MySQL server. (Bug#33397)

Executing a FLUSH PRIVILEGES statement after creating a temporary table in the mysql database with the same name as one of the MySQL system tables caused the server to crash.

(Bug#33275)

Selecting from a view that referenced the same table in the FROM clause and an IN clause caused a server crash. (Bug#33245)

When creating a new tablespace and specifying the name of an existing tablespace file, an incorrect error message would be reported specifying that the tablespace already existed. The error message has been updated to reflect the actual error. (Bug#33213)

There was a race condition between the event scheduler and the server shutdown thread. (Bug#32771)

Assignment of relative path names to general_log_file or slow_query_log_file did not always work. (Bug#32748)

Deeply nested subqueries could cause stack overflow or a server crash. (Bug#32680)

Query results from a FEDERATED table were corrupt if the query included an ORDER BY on a TEXT column. (Bug#32426)

Conversion of binary values to multi-byte character sets could fail to left-pad values to the correct length. This could result in a server crash. (Bug#32394)

On all x86 platforms, the default was to attempt to build the server with the Falcon storage engine, even if Falcon was not supported for a given platform. (Bug#32287)

Killing a statement that invoked a stored function could return an incorrect error message indicating table corruption rather than that the statement had been interrupted. (Bug#32140)

Occurrence of an error within a stored routine did not always cause immediate statement termination. (Bug#31881)

For DROP FUNCTION db_name.func_name (that is, when the function name is qualified with the database name), the statement should apply only to a stored function named func_name in the given database. However, if a UDF with the same name existed, the statement dropped the UDF instead. (Bug#31767)

On NetWare, mysql_install_db could appear to execute normally even if it failed to create the initial databases. (Bug#30129)

A problem related to HP-UX compilers that caused incorrect WEIGHT_STRING() results was fixed. (Bug#29825)

TRUNCATE TABLE for InnoDB tables returned a count showing too many rows affected. Now the statement returns 0 for InnoDB tables. (Bug#29507)

InnoDB could return an incorrect rows-updated value for UPDATE statements. (Bug#29157)

The mysql.servers table was not created during installation on Windows. (Bug#28680, Bug#32797)

The jp test suite was not working. (Bug#28563)

The internal init_time() library function was renamed to my_init_time() to avoid conflicts with external libraries. (Bug#26294)

In some cases, the parser interpreted the ; character as the end of input and misinterpreted stored program definitions. (Bug#26030)

Statements to create, alter, or drop a view were not waiting for completion of statements that were using the view, which led to incorrect sequences of statements in the binary log when statement-based logging was enabled. (Bug#25144)

The Questions status variable is intended as a count of statements sent by clients to the server, but was also counting statements executed within stored routines. (Bug#24289)

InnoDB exhibited thread thrashing with more than 50 concurrent connections under an update-intensive workload. (Bug#22868)

DROP DATABASE did not drop orphaned FOREIGN KEY constraints. (Bug#18942)

Delayed-insert threads were counted as connected but not as created, incorrectly leading to a Threads_connected value greater than the Threads_created value. (Bug#17954)

The parser used signed rather than unsigned values in some cases that caused legal lengths in column declarations to be rejected. (Bug#15776)

Stored procedure exception handlers were catching fatal errors (such as out of memory errors), which could cause execution not to stop to due a continue handler. Now fatal errors are not caught by exception handlers and a fatal error is returned to the client. (Bug#15192)

On Windows, moving an InnoDB .ibd file and then symlinking to it in the database directory using a .sym file caused a server crash. (Bug#11894)

If a connection was waiting for a GET_LOCK() lock or a SLEEP() call, and the connection aborted, the server did not detect this and thus did not close the connection. This caused a waste of system resources allocated to dead connections. Now the server checks such a connection every five seconds to see whether it has been aborted. If so, the connection is killed (and any lock request is aborted). (Bug#10374)

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.

In MySQL 5.1.x, this bug was addressed twice because it turned out that the default was set in two places, only one of which was fixed the first time. (Bug#29993)

Incompatible Change: The server now includes dtoa, a library for conversion between strings and numbers by David M. Gay. In MySQL, this library provides the basis for improved conversion between string or DECIMAL values and approximate-value (FLOAT/DOUBLE) numbers:

Because the conversions produced by this library differ in some cases from previous results, the potential exists for incompatibilities in applications that rely on previous results. For example, applications that depend on a specific exact result from pre