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

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)

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)

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

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)

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

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)

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

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)

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)

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)

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)

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)

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)

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 non-existent 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)

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)

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)

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)

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)

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

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)

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)

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

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)

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)

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

Important Change: Replication: If a trigger was defined on an InnoDB table and this trigger updated a non-transactional 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 non-transactional and transactional tables in a transaction in the first statement of a transaction have changed. Previously, if the first statement in a transaction contained non-transactional 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 non-transactional 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 non-transactional 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)

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

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)

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)

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, non-matching 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 optimizer could ignore an error and rollback request during a filesort, causing an assertion failure. (Bug#41543)

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)

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)

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

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)

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)

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

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)

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)

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)

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)

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

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 non-string 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 non-alphanumeric 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.

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 non-latin 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)

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 non-partial 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 non-integer operands that exceed BIGINT range. Now, if either operand has a non-integer 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 non-matching 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 non-partitioned 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 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 non-existent tablespace. (Bug#39702)

With the ONLY_FULL_GROUP_BY SQL mode enabled, the check for non-aggregated 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 non-aggregated 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 non-directory 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 non-existent 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 non-index 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)

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 non-covering 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 non-debug 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 non-standard 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 non-empty 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 non-existent 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 non-existant 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 this release, no logging option changes should be necessary. However, if you are upgrading from 5.1.6 through 5.1.20 to this release 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 previous conversions might need adjustment to accommodate additional precision.

For additional information about the properties of dtoa conversions, see Section 11.2.2, “Type Conversion in Expression Evaluation”.

See also Bug#12860, Bug#21497, Bug#26788, Bug#24541, Bug#34015.

Important Change: MySQL Cluster: Packaging: Beginning with this release, standard MySQL 6.0 binaries are no longer built with support for the NDBCLUSTER storage engine, and the NDBCLUSTER code included in 6.0 mainline sources is no longer guaranteed to be maintained or supported. Those using MySQL Cluster in MySQL 6.0.4 and earlier MySQL 6.0 mainline releases should upgrade to MySQL Cluster NDB 6.2.15 or a later MySQL Cluster NDB 6.2 or 6.3 release. (Bug#36193)

Important Change: Added a ROUTINE_TYPE column to the INFORMATION_SCHEMA.PARAMETERS table, to make it possible to distinguish like-named parameters of stored routines and stored functions having the same names. See Section 19.27, “The INFORMATION_SCHEMA PARAMETERS Table”, for more information. (Bug#33106)

Replication: Introduced the slave_exec_mode system variable to control whether idempotent or strict mode is used for replication conflict resolution. Idempotent mode suppresses duplicate-key, no-key-found, and some other errors, and is needed for circular replication, multi-master replication, and some other complex replication setups when using MySQL Cluster. Strict mode is the default. (Bug#31609)

Replication: When running the server with --binlog-format=MIXED or --binlog-format=STATEMENT, a query that referred to a system variable used the slave's value when replayed on the slave. This meant that, if the value of a system variable was inserted into a table, the slave differed from the master. Now, statements that refer to a system variable are marked as “unsafe”, which means that:

(Bug#31168)

See also Bug#34732.

In the INFORMATION_SCHEMA database, the FALCON_DATABASE_IO table was renamed to FALCON_TABLESPACE_IO. (Bug#35490)

For boolean options, the option-processing library now prints additional information in the --help message: If the option is enabled by default, the message says so and indicates that the --skip form of the option disables the option. This affects all compiled MySQL programs that use the library. (Bug#35224)

The PROCESS privilege now is required to start or stop the InnoDB monitor tables (see Section 13.7.13.2, “SHOW ENGINE INNODB STATUS and the InnoDB Monitors”). Previously, no privilege was required. (Bug#34053)

For binary .tar.gz packages, mysqld and other binaries now are compiled with debugging symbols included to enable easier use with a debugger. If you do not need debugging symbols and are short on disk space, you can use strip to remove the symbols from the binaries. (Bug#33252)

Several undocumented C API functions were removed: mysql_manager_close(), mysql_manager_command(), mysql_manager_connect(), mysql_manager_fetch_line(), and mysql_manager_init(). (Bug#31954)

The C API contained several undocumented functions that have been removed: mysql_disable_reads_from_master(), mysql_disable_rpl_parse(), mysql_enable_reads_from_master(), mysql_enable_rpl_parse(), mysql_master_query(), mysql_master_send_query(), mysql_reads_from_master_enabled(), mysql_rpl_parse_enabled(), mysql_rpl_probe(), mysql_rpl_query_type(), mysql_set_master(), mysql_slave_query(), and mysql_slave_send_query(). (Bug#31952)

Formerly, when the MySQL server crashed, the generated stack dump was numeric and required external tools to properly resolve the names of functions. This is not very helpful to users having a limited knowledge of debugging techniques. In addition, the generated stack trace contained only the names of functions and was formatted differently for each platform due to different stack layouts.

Now it is possible to take advantage of newer versions of the GNU C Library provide a set of functions to obtain and manipulate stack traces from within the program. On systems that use the ELF binary format, the stack trace contains important information such as the shared object where the call was generated, an offset into the function, and the actual return address. Having the function name also makes possible the name demangling of C++ functions.

The library generates meaningful stack traces on the following platforms: i386, x86_64, PowerPC, IA64, Alpha, and S390. On other platforms, a numeric stack trace is still produced, and the use of the resolve_stack_dump utility is still required. (Bug#31891)

mysqltest now has mkdir and rmdir commands for creating and removing directories. (Bug#31004)

The LAST_EXECUTED column of the INFORMATION_SCHEMA.EVENTS table now indicates when the event started executing rather than when it finished executing. As a result, the ENDS column is never less than LAST_EXECUTED. (Bug#29830)

The mysql_odbc_escape_string() C API function has been removed. It has multi-byte character escaping issues, doesn't honor the NO_BACKSLASH_ESCAPES SQL mode and is not needed anymore by Connector/ODBC as of 3.51.17. (Bug#29592)

The server uses less memory when loading privileges containing table grants. (Patch provided by Google.) (Bug#25175)

Added the Uptime_since_flush_status status variable, which indicates the number of seconds since the most recent FLUSH STATUS statement. (Community contribution by Jeremy Cole) (Bug#24822)

Added the SHOW PROFILES and SHOW PROFILE statements to display statement profile data, and the accompanying INFORMATION_SCHEMA.PROFILING table. Profiling is controlled via the profiling and profiling_history_size session variables. see Section 12.5.6.32, “SHOW PROFILES Syntax”, and Section 19.28, “The INFORMATION_SCHEMA PROFILING Table”. (Community contribution by Jeremy Cole)

The profiling feature is enabled via the --enable-community-features and --enable-profiling options to configure. These options are enabled by default; to disable them, use --disable-community-features and --disable-profiling. (Bug#24795)

The performance of internal functions that trim multiple spaces from strings when comparing them has been improved. (Bug#14637)

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

The new read-only global system variables report_host, report_password, report_port, and report_user system variables provide runtime access to the values of the corresponding --report-host, --report-password, --report-port, and --report-user options.

Formerly it was possible to specify an innodb_flush_method value of fdatasync to obtain the default flush behavior of using fdatasync() for flushing. This is no longer possible because it can be confusing that a value of fdatasync causes use of fsync() rather than fdatasync().

The use of InnoDB hash indexes now can be controlled by setting the new innodb_adaptive_hash_index system variable at server startup. By default, this variable is enabled. See Section 13.7.10.4, “Adaptive Hash Indexes”.

The argument for the mysql-test-run.pl --do-test and --skip-test options is now interpreted as a Perl regular expression if there is a pattern metacharacter in the argument value. This allows more flexible specification of which tests to perform or skip.

The Instance Manager (mysqlmanager) has been discontinued and is no longer provided in MySQL releases.

For Falcon, supernodes have been added to index pages. Supernodes are an array of 16 vectors into each index page to keys that are fully expanded with noprefix compression. This allows the page to be searched quicker using a binary search of supernode keys followed by the normal sequential search. Without enabling supernodes, the whole page has to be searched sequentially.

Two new statements, BACKUP DATABASE and RESTORE, have been added for backup and restore operations. See Section 6.3, “Using MySQL Backup”.

Important Change: Security Fix: It was possible to circumvent privileges through the creation of MyISAM tables employing the DATA DIRECTORY and INDEX DIRECTORY options to overwrite existing table files in the MySQL data directory. Use of the MySQL data directory in DATA DIRECTORY and INDEX DIRECTORY is now disallowed. This is now also true of these options when used with partitioned tables and individual partitions of such tables.

(Bug#32167, CVE-2008-2079)

See also Bug#39277.

Security Fix: A client that connects to a malicious server could be tricked by the server into sending files from the client host to the server. This occurs because the libmysqlclient client library would respond to a FETCH LOCAL FILE request from the server even if the request is sent for statements from the client other than LOAD DATA LOCAL INFILE. The client library has been modified to respond to a FETCH LOCAL FILE request from the server only if is is sent in response to a LOAD DATA LOCAL INFILE statement from the client.

The client library now also checks whether CLIENT_LOCAL_FILE is set and refuses to send a local file if not.

(Bug#29605)

Important Change: Security Enhancement: On Windows Vista and Windows Server 2008, a user without administrative privileges does not have write permissions to the Program Files directory where MySQL and the associated data files are normally installed. Using data files located in the standard Program Files installation directory could therefore cause MySQL to fail, or lead to potential security issues in an installed instance.

To address the problem, on Windows XP, Windows Vista and Windows Server 2008, the datafiles and data file configuration are now set to the Microsoft recommended AppData folder. The AppData folder is typically located within the user's home directory.

(Bug#34593)

Security Enhancement: It was possible to force an error message of excessive length which could lead to a buffer overflow. This has been made no longer possible as a security precaution. (Bug#32707)

Incompatible Change: In MySQL 5.1.23, the last_errno and last_error members of the NET structure in mysql_com.h were renamed to client_last_errno and client_last_error. This was found to cause problems for connectors that use the internal NET structure for error handling. The change has been reverted. (Bug#34655)

See also Bug#12713.

Incompatible Change: The parser accepted illegal syntax in a FOREIGN KEY clause:

These illegal syntaxes are now properly rejected. Existing applications that used them will require adjustment. (Bug#34455)

Incompatible Change: It was possible to use FRAC_SECOND as a synonym for MICROSECOND with DATE_ADD(), DATE_SUB(), and INTERVAL; now, using FRAC_SECOND with anything other than TIMESTAMPADD() or TIMESTAMPDIFF() produces a syntax error.

It is now possible (and preferable) to use MICROSECOND with TIMESTAMPADD() and TIMESTAMPDIFF(), and FRAC_SECOND is now deprecated. (Bug#33834)

Incompatible Change: The UPDATE statement allowed NULL to be assigned to NOT NULL columns (the implicit default value for the column data type was assigned). This was changed so that on error occurs.

This change was reverted, because the original report was determined not to be a bug: Assigning NULL to a NOT NULL column in an UPDATE statement should produce an error only in strict SQL mode and set the column to the implicit default with a warning otherwise, which was the original behavior. See Section 10.1.4, “Data Type Default Values”, and Bug#39265. (Bug#33699)

Incompatible Change: It is no longer possible to create CSV tables with NULL columns. However, for backwards compatibility, you can continue to use such tables that were created in previous MySQL releases. (Bug#32050)

Incompatible Change: For packages that are built within their own prefix (for example, /usr/local/mysql) the plugin directory will be lib/plugin. For packages that are built to be installed into a system-wide prefix (such as RPM packages with a prefix of /usr), the plugin directory will be lib/mysql/plugin to ensure a clean /usr/lib hierarchy. In both cases, the $pkglibdir configuration setting is used at build time to set the plugin directory.

The current plugin directory location is available as the value of the plugin_dir system variable as before, but the mysql_config script now has a --plugindir option that can be used externally to the server by third-party plugin writers to obtain the default plugin directory path name and configure their installation directory appropriately. (Bug#31736)

Incompatible Change: Inserting a row with a NULL value for a DATETIME column results in a CSV file that the storage engine cannot read.

All CSV tables now need to be defined with each column marked as NOT NULL. An error is raised if you try to create a CSV table with columns that are not defined with NOT NULL. (Bug#31473, Bug#32817)

Incompatible Change: The utf8_general_ci and ucs2_general_ci collations did not sort the letter "U+00DF SHARP S" equal to 's'.

As a result of this fix, any indexes on columns that use these collations (but only columns that use SHARP S) must be rebuilt when upgrading to 6.0.5 or higher. To do this, use ALTER TABLE to drop and re-add the indexes, or use mysqldump to dump the affected tables and mysql to reload the dump file. (Bug#27877)

See also Bug#37046.

Incompatible Change: Several changes were made to the processing of multiple-table DELETE statements:

Statements containing alias constructs that are no longer allowed must be rewritten. (Bug#27525)

See also Bug#30234.

Important Change: Replication: When the master crashed during an update on a transactional table while in autocommit mode, the slave failed. This fix causes every transaction (including autocommit transactions) to be recorded in the binlog as starting with a BEGIN and ending with a COMMIT or ROLLBACK. (Bug#26395)

Important Change: InnoDB free space information is now shown in the Data_free column of SHOW TABLE STATUS and in the DATA_FREE column of the INFORMATION_SCHEMA.TABLES table. (Bug#32440)

See also Bug#11379.

Important Change: The server handled truncation of values having excess trailing spaces into CHAR, VARCHAR, and TEXT columns in different ways. This behavior has now been made consistent for columns of all three of these types, and now follows the existing behavior of VARCHAR columns in this regard; that is, a Note is always issued whenever such truncation occurs.

This change does not affect columns of these three types when using a binary encoding; BLOB columns are also unaffected by the change, since they always use a binary encoding. (Bug#30059)

Important Change: An AFTER UPDATE trigger was not invoked when the UPDATE did not make any changes to the table for which the trigger was defined. Now AFTER UPDATE triggers behave the same in this regard as do BEFORE UPDATE triggers, which are invoked whether the UPDATE makes any changes in the table or not. (Bug#23771)

Partitioning: Important Note: The following statements did not function correctly with corrupted or crashed tables and have been disabled:

ALTER TABLE ... REBUILD PARTITION is unaffected by this change and continues to be available. This statement and ALTER TABLE ... REORGANIZE PARTITION may be used to analyze and optimize partitioned tables, since these operations cause the partition files to be rebuilt. (Bug#20129)

See also Bug#39434.

Replication: Important Note: Network timeouts between the master and the slave could result in corruption of the relay log. This fix rectifies a long-standing replication issue when using unreliable networks, including replication over wide area networks such as the Internet. If you experience reliability issues and see many You have an error in your SQL syntax errors on replication slaves, we strongly recommend that you upgrade to a MySQL version which includes this fix. (Bug#26489)

MySQL Cluster: When all data and SQL nodes in the cluster were shut down abnormally (that is, other than by using STOP in the cluster management client), ndb_mgm used excessive amounts of CPU. (Bug#33237)

MySQL Cluster: There was a short interval during the startup process prior to the beginning of heartbeat detection such that, were an API or management node to reboot or a network failure to occur, data nodes could not detect this, with the result that there could be a lingering connection. (Bug#28445)

Partitioning: In some cases, matching rows from a partitioned MyISAM using a BIT column as the primary key were not found by queries. (Bug#34358)

Partitioning: Enabling innodb_file_per_table produced problems with partitioning and tablespace operations on partitioned InnoDB tables, in some cases leading to corrupt partitions or causing the server to crash. (Bug#33429)

Partitioning: A table defined using PARTITION BY KEY and having a BIT column referenced in the partitioning key did not behave correctly; some rows could be inserted into the wrong partition, causing wrong results to be returned from queries. (Bug#33379)

Partitioning: It was possible to partition a table to which a foreign key referred. (Bug#32948)

Partitioning: When ALTER TABLE DROP PARTITION was executed on a table on which there was a trigger, the statement failed with an error. This occurred even if the trigger did not reference any tables. (Bug#32943)

Partitioning: A query of the form SELECT col1 FROM table GROUP BY (SELECT col2 FROM table LIMIT 1); against a partitioned table having a SET column crashed the server. (Bug#32772)

Partitioning: SHOW CREATE TABLE misreported the value of AUTO_INCREMENT for partitioned tables using either of the InnoDB or ARCHIVE storage engines. (Bug#32247)

Partitioning: Selecting from INFORMATION_SCHEMA.PARTITIONS while partition management statements (for example, ALTER TABLE ... ADD PARTITION) were executing caused the server to crash. (Bug#32178)

Partitioning: An error in the internal function mysql_unpack_partition() led to a fatal error in subsequent calls to open_table_from_share(). (Bug#32158)

Partitioning: Currently, all partitions of a partitioned table must use the same storage engine. One may optinally specify the storage engine on a per-partition basis; however, where this is the done, the storage engine must be the same as used by the table as a whole. ALTER TABLE did not enforce these rules correctly, the result being that incaccurate error messages were shown when trying to use the statement to change the storage engine used by an individual partition or partitions. (Bug#31931)

Partitioning: ORDER BY ... DESC did not always work correctly when selecting from partitioned tables. (Bug#31890)

See also Bug#31001.

Partitioning: ALTER TABLE ... COALESCE PARTITION on a table partitioned by [LINEAR] HASH or [LINEAR] KEY caused the server to crash. (Bug#30822)

Partitioning: When the range access method was used on a partitioned Falcon table, the entire index was scanned. For partitioned tables using other storage engines, a related issue caused an ordered range scan to return some rows twice. (Bug#30573, Bug#33257, Bug#33555)

Partitioning: LIKE queries on tables partitioned by KEY could return incomplete results. The problem was observed with the Falcon storage engine, but could affect third-party storage engines as well. (Bug#30480)

See also Bug#29320, Bug#29493, Bug#30563.

Partitioning: Using the DATA DIRECTORY and INDEX DIRECTORY options for partitions with CREATE TABLE or ALTER TABLE statements appeared to work on Windows, although they are not supported by MySQL on Windows systems, and subsequent attempts to use the tables referenced caused errors. Now these options are disabled on Windows, and attempting to use them generates a warning. (Bug#30459)

Partitioning: It was not possible to insert the greatest possible value for a given data type into a partitioned table. For example, consider a table defined as shown here:

CREATE TABLE t (c BIGINT UNSIGNED)
    PARTITION BY RANGE(c) (
      PARTITION p0 VALUES LESS THAN MAXVALUE
    );

The largest possible value for a BIGINT UNSIGNED column is 18446744073709551615, but the statement INSERT INTO t VALUES (18446744073709551615); would fail, even though the same statement succeeded were t not a partitioned table.

In other words, MAXVALUE was treated as being equal to the greatest possible value, rather than as a least upper bound. (Bug#29258)

Replication: Replicating a Falcon table that contained a TEXT or BLOB column would fail during a DELETE operation with the error HA_ERR_END_OF_FILE. (Bug#36468)

Replication: When using row-based replication, a slave could crash at startup because it received a row-based replication event that InnoDB could not handle due to an incorrect test of the query string provided by MySQL, which was NULL for row-based replication events. (Bug#35226)

Replication: insert_id was not written to the binary log for inserts into BLACKHOLE tables. (Bug#35178)

Replication: When using statement-based replication and a DELETE, UPDATE, or INSERT ... SELECT statement using a LIMIT clause is encountered, a warning that the statement is not safe to replicate in statement mode is now issued; when using MIXED mode, the statement is now replicated using the row-based format. (Bug#34768)

Replication: mysqlbinlog did not output the values of auto_increment_increment and auto_increment_offset when both were equal to their default values (for both of these variables, the default is 1). This meant that a binary log recorded by a client using the defaults for both variables and then replayed on another client using its own values for either or both of these variables produced erroneous results. (Bug#34732)

See also Bug#31168.

Replication: A CHANGE MASTER TO statement with no MASTER_HEARTBEAT_PERIOD option failed to reset the heartbeat period to its default value. (Bug#34686)

Replication: SHOW SLAVE STATUS failed when slave I/O was about to terminate. (Bug#34305)

Replication: The character sets and collations used for constant identifiers in stored procedures were not replicated correctly. (Bug#34289)

Replication: mysqlbinlog from a 5.1 or later MySQL distribution could not read binary logs generated by a 4.1 server when the logs contained LOAD DATA INFILE statements. (Bug#34141)

This regression was introduced by Bug#32407.

Replication: A CREATE USER, DROP USER, or RENAME USER statement that fails on the master, or that is a duplicate of any of these statements, is no longer written to the binlog; previously, either of these occurrences could cause the slave to fail.

(Bug#33862)

See also Bug#29749.

Replication: SHOW BINLOG EVENTS could fail when the binlog contained one or more events whose size was close to the value of max_allowed_packet. (Bug#33413)

Replication: mysqlbinlog failed to release all of its memory after terminating abnormally. (Bug#33247)

Replication: When a stored routine or trigger, running on a master that used MySQL 5.0 or MySQL 5.1.11 or earlier, performed an insert on an AUTO_INCREMENT column, the insert_id value was not replicated correctly to a slave running MySQL 5.1.12 or later (including any MySQL 6.0 release). (Bug#33029)

See also Bug#19630.

Replication: The error message generated due to lack of a default value for an extra column was not sufficiently informative. (Bug#32971)

Replication: When a user variable was used inside an INSERT statement, the corresponding binlog event was not written to the binlog correctly. (Bug#32580)

Replication: When using row-based replication, deletes from a table with a foreign key constraint failed on the slave. (Bug#32468)

Replication: The --base64-output option for mysqlbinlog was not honored for all types of events. This interfered in some cases with performing point-in-time recovery. (Bug#32407)

Replication: SQL statements containing comments using -- syntax were not replayable by mysqlbinlog, even though such statements replicated correctly. (Bug#32205)

Replication: When using row-based replication from a master running MySQL 6.0.3 or earlier to a slave running 6.0.4 or later, updates of integer columns failed on the slave with Error in Unknown event: row application failed. (Bug#31583)

This regression was introduced by Bug#21842.

Replication: Replicating write, update, or delete events from a master running MySQL 5.1.15 or earlier to a slave running 5.1.16 or later caused the slave to crash. (Bug#31581)

Replication: When using row-based replication, the slave stopped when attempting to delete non-existent rows from a slave table without a primary key. In addition, no error was reported when this occurred. (Bug#31552)

Replication: Errors due to server ID conflicts were reported only in the slave's error log; now these errors are also shown in the Server_IO_State column in the output of SHOW SLAVE STATUS. (Bug#31316)

Replication: STOP SLAVE did not stop connection attempts properly. If the IO slave thread was attempting to connect, STOP SLAVE waited for the attempt to finish, sometimes for a long period of time, rather than stopping the slave immediately. (Bug#31024)

See also Bug#30932.

Replication: Issuing a DROP VIEW statement caused replication to fail if the view did not actually exist. (Bug#30998)

Replication: Replication of LOAD DATA INFILE could fail when read_buffer_size was larger than max_allowed_packet. (Bug#30435)

Replication: Replication crashed with the NDB storage engine when mysqld was started with --character-set-server=ucs2. (Bug#29562)

Replication: The effects of scheduled events were not always correctly reproduced on the slave when using row-based replication. (Bug#29020)

Replication: Setting server_id did not update its value for the current session. (Bug#28908)

Replication: Some older servers wrote events to the binary log using different numbering from what is currently used, even though the file format number in the file is the same. Slaves running MySQL 5.1.18 and later could not read these binary logs properly. Binary logs from these older versions now are recognized and event numbers are mapped to the current numbering so that they can be interpreted properly. (Bug#27779, Bug#32434)

This regression was introduced by Bug#22583.

Replication: MASTER_POS_WAIT() did not return NULL when the server was not a slave. (Bug#26622)

Replication: The inspecific error message Wrong parameters to function register_slave resulted when START SLAVE failed to register on the master due to excess length of any the slave server options --report-host, --report-user, or --report-password. An error message specific to each of these options is now returned in such cases. The new error messages are:

(Bug#22989)

See also Bug#19328.

Replication: PURGE BINARY LOGS TO and PURGE BINARY LOGS BEFORE did not handle missing binary log files correctly or in the same way. Now for both of these statements, if any files listed in the .index file are missing from the file system, the statement fails with an error.

API: When the language option was not set correctly, API programs calling mysql_server_init() crashed. This issue was observed only on Windows platforms. (Bug#31868)

Corrected a typecast involving bool on Mac OS X 10.5 (Leopard), which evaluated differently from earlier Mac OS X versions. (Bug#38217)

Queries could return different results depending on whether the join buffer was or was not used. (Bug#37131)

BACKUP DATABASE did not correctly determine dependency ordering of backed-up objects, which could cause a RESTORE operation to fail. (Bug#36531)

Concurrent LOAD DATA INFILE statements inserting data into Falcon tables could crash the server. (Bug#35982)

Following a server crash, recovery of Falcon tables containing BLOB or TEXT columns could lose data. (Bug#35688)

Manually replacing a binary log file with a directory having the same name caused an error that was not handled correctly. (Bug#35675)

Using LOAD DATA INFILE with a view could crash the server. (Bug#35469)

Selecting from INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS could cause a server crash. (Bug#35406)

See also Bug#35108.

For a TEMPORARY table, DELETE with no WHERE clause could fail when preceded by DELETE statements with a WHERE clause. (Bug#35392)

In some cases, when too many clients tried to connect to the server, the proper SQLSTATE code was not returned. (Bug#35289)

Memory-allocation failures for attempts to set key_buffer_size to large values could result in a server crash. (Bug#35272)

Queries could return different results depending on whether ORDER BY columns were indexed. (Bug#35206)

When a view containing a reference to DUAL was created, the reference was removed when the definition was stored, causing some queries against the view to fail with invalid SQL syntax errors. (Bug#35193)

SELECT ... FROM INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS caused the server to crash if the table referenced by a foreign key had been dropped. This issue was observed on Windows platforms only. (Bug#35108)

See also Bug#35406.

Debugging symbols were missing for some executables in Windows binary distributions. (Bug#35104)

Non-connection threads were being counted in the value of the Max_used_connections status variable. (Bug#35074)

Two different threads could obtain the same record number for concurrent inserts into the same Falcon table. (Bug#34990)

A query that performed a ref_or_null join where the second table used a key having one or columns that could be NULL and had a column value that was NULL caused the server to crash. (Bug#34945)

This regression was introduced by Bug#12144.

For some queries, the optimizer used an ordered index scan for GROUP BY or DISTINCT when it was supposed to use a loose index scan, leading to incorrect results. (Bug#34928)

Creating a foreign key on an InnoDB table that was created with an explicit AUTO_INCREMENT value caused that value to be reset to 1. (Bug#34920)

mysqldump failed to return an error code when using the --master-data option without binary logging being enabled on the server. (Bug#34909)

Under some circumstances, the value of mysql_insert_id() following a SELECT ... INSERT statement could return an incorrect value. This could happen when the last SELECT ... INSERT did not involve an AUTO_INCREMENT column, but the value of mysql_insert_id() was changed by some previous statements. (Bug#34889)

Logging to the progress tables used by BACKUP DATABASE and RESTORE caused a server crash. (Bug#34858)

Table and database names were mixed up in some places of the subquery transformation procedure. This could affect debugging trace output and further extensions of that procedure. (Bug#34830)

If fsync() returned ENOLCK, InnoDB could treat this as fatal and cause abnormal server termination. InnoDB now retries the operation. (Bug#34823)

CREATE SERVER and ALTER SERVER could crash the server if out-of-memory conditions occurred. (Bug#34790)

DROP SERVER does not release memory cached for server structures created by CREATE SERVER, so repeated iterations of these statements resulted in a memory leak. FLUSH PRIVILEGES now releases the memory allocated for CREATE SERVER. (Bug#34789)

A malformed URL used for a FEDERATED table's CONNECTION option value in a CREATE TABLE statement was not handled correctly and could crash the server. (Bug#34788)

Repeated UPDATE operations on a Falcon table could cause a memory leak. (Bug#34778)

Queries such as SELECT ROW(1, 2) IN (SELECT t1.a, 2) FROM t1 GROUP BY t1.a (combining row constructors and subqueries in the FROM clause) could lead to assertion failure or unexpected error messages. (Bug#34763)

Using NAME_CONST() with a negative number and an aggregate function caused MySQL to crash. This could also have a negative impact on replication. (Bug#34749)

A memory-handling error associated with use of GROUP_CONCAT() in subqueries could result in a server crash. (Bug#34747)

For an indexed integer column col_name and a value N that is one greater than the maximum value allowed for the data type of col_name, conditions of the form WHERE col_name < N failed to return rows where the value of col_name is N - 1. (Bug#34731)

A server running with the --debug option could attempt to dereference a null pointer when opening tables, resulting in a crash. (Bug#34726)

Assigning an “incremental” value to the debug system variable did not add the new value to the current value. For example, if the current debug value was 'T', the statement SET debug = '+P' resulted in a value of 'P' rather than the correct value of 'P:T'. (Bug#34678)

For debug builds, reading from INFORMATION_SCHEMA.TABLES or INFORMATION_SCHEMA.COLUMNS could cause assertion failures. This could happen under rare circumstances when INFORMATION_SCHEMA fails to get information about a table (for example, when a connection is killed). (Bug#34656)

Executing a TRUNCATE statement on a table having both a foreign key reference and a DELETE trigger crashed the server. (Bug#34643)

Some subqueries using an expression that included an aggregate function could fail or in some cases lead to a crash of the server. (Bug#34620)

Dangerous pointer arithmetic crashed the server on some systems. (Bug#34598)

Creating a view inside a stored procedure could lead to a crash of the MySQL Server. (Bug#34587)

Concurrent ALTER TABLE operations on temporary and non-temporary Falcon tables caused the server to hang. (Bug#34567)

This regression was introduced by Bug#33634.

A server crash could occur if INFORMATION_SCHEMA tables built in memory were swapped out to disk during query execution. (Bug#34529)

CAST(AVG(arg) AS DECIMAL) produced incorrect results for non-DECIMAL arguments. (Bug#34512)

SET GLOBAL falcon_record_chill_threshold and SET GLOBAL falcon_index_chill_threshold did not work. (Bug#34486)

The per-thread debugging settings stack was not being deallocated before thread termination, resulting in a stack memory leak. (Bug#34424)

Client applications could not connect to the server on Windows Vista because the server was creating an IPv6-only TCP/IP socket. (Bug#34381)

Inserting a unique record into a Falcon table, then performing a DELETE on the same record resulted in the error Record has changed since last read. (Bug#34351)

See also Bug#29151, Bug#35321.

Executing an ALTER VIEW statement on a table crashed the server. (Bug#34337)

For InnoDB, exporting and importing a table could corrupt TINYBLOB columns, and a subsequent ALTER TABLE could corrupt TINYTEXT columns as well. (Bug#34300)

On Windows, client programs generated assertion failures. (Bug#34298)

DEFAULT 0 was not allowed for the YEAR data type. (Bug#34274)

Under some conditions, a SET GLOBAL innodb_commit_concurrency or SET GLOBAL innodb_autoextend_increment statement could fail. (Bug#34223)

mysqldump attempts to set the character_set_results system variable after connecting to the server. This failed for pre-4.1 servers that have no such variable, but mysqldump did not account for this and 1) failed to dump database contents; 2) failed to produce any error message alerting the user to the problem. (Bug#34192)

Use of stored functions in the WHERE clause for SHOW OPEN TABLES caused a server crash. (Bug#34166)

Compilation failed on Solaris for the ARCHIVE storage engine due to inclusion of getopt.h in the ARCHIVE code. (Bug#34094)

CREATE TABLE ... ENGINE=Falcon failed with an unhelpful error message when the Falcon storage engine had failed to allocate the page cache properly on server startup. Now, Falcon is initialized on server startup, and is not loaded if the allocation fails. (Bug#34085)

Updates of floating-point columns in FEDERATED tables could produce incorrect results. (Bug#34015)

For a FEDERATED table with an index on a nullable column, accessing the table could crash a server, return an incorrect result set, or return ERROR 1030 (HY000): Got error 1430 from storage engine. (Bug#33946)

Passing anything other than a integer to a LIMIT clause in a prepared statement would fail. (This limitation was introduced to avoid replication problems; for example, replicating the statement with a string argument would cause a parse failure in the slave). Now, arguments to the LIMIT clause are converted to integer values, and these converted values are used when logging the statement. (Bug#33851)

An internal buffer in mysql was too short. Overextending it could cause stack problems or segmentation violations on some architectures. (This is not a problem that could be exploited to run arbitrary code.) (Bug#33841)

A query using WHERE (column1='string1' AND column2=constant1) OR (column1='string2' AND column2=constant2), where col1 used a binary collation and string1 matched string2 except for case, failed to match any records even when matches were found by a query using the equivalent clause WHERE column2=constant1 OR column2=constant2. (Bug#33833)

Large unsigned integers were improperly handled for prepared statements, resulting in truncation or conversion to negative numbers. (Bug#33798)

Reuse of prepared statements could cause a memory leak in the embedded server. (Bug#33796)

The server crashed when executing a query that had a subquery containing an equality X=Y where Y referred to a named select list expression from the parent select. The server crashed when trying to use the X=Y equality for ref-based access. (Bug#33794)

Some queries using a combination of IN, CONCAT(), and an implicit type conversion could return an incorrect result. (Bug#33764)

In some cases a query that produced a result set when using ORDER BY ASC did not return any results when this was changed to ORDER BY DESC. (Bug#33758)

Disabling concurrent inserts caused some cacheable queries not to be saved in the query cache. (Bug#33756)

ORDER BY ... DESC sorts could produce misordered results. (Bug#33697)

Use of uninitialized memory for filesort in a subquery caused a server crash. (Bug#33675)

The WEIGHT_STRING() function returned incorrect results for column values when earlier column values were NULL. (Bug#33663)

The server could crash when REPEAT or another control instruction was used in conjunction with labels and a LEAVE instruction. (Bug#33618)

The parser allowed control structures in compound statements to have mismatched beginning and ending labels. (Bug#33618)

make_binary_distribution passed the --print-libgcc-file option to the C compiler, but this does not work with the ICC compiler. (Bug#33536)

Threads created by the event scheduler were incorrectly counted against the max_connections thread limit, which could lead to client lockout. (Bug#33507)

CREATE TABLE ... ENGINE=Falcon failed on kernel 2.4 based Linux systems when using O_DIRECT with an NFS file system. (Bug#33484)