MySQL 6.0.11アルファ版がリリースされました。


MySQLデータベースシステムの新バージョンであるMySQL 6.0.11アルファ版がリリースされました。MySQL 6.0に関する主要なページは、にあります。

MySQL 6.0.11は6.0の最終リリースです。今後は、MySQL Serverの新リリースモデルに移行する予定です。


2009年9月には、MySQL 6.0からの機能のほとんどを含むことを予定しています。より詳細については、6月末までにはお伝えする予定です。この予定(オンラインバックアップ、Falcon、コネクションスレッドプーリング、4バイトUTFのサポートなど)にない機能は、安定版以降に検討する予定です。

MySQL 6.0は、トランザクションのFalconエンジンと、クラッシュ・セーフなMariaエンジンの二つの新たなストレージエンジンを含んでいます。

Falconストレージエンジンが初めてで、より多くの情報が必要な場合、Falcon Evaluation Guide

と、Falcon White Paper

Mariaストレージエンジンは、MyISAMのクラッシュ・セーフなバージョンです。MariaはMyISAMエンジンの主な機能のすべてをサポートします。それだけでなく、システムクラッシュが発生した場合のリカバリサポート、CREATE, DROP, RENAME, TRUNCATEを含む十分なロギング機能、全てのMyISAMテーブルのrow format、Maria固有の新たなrow formatもMariaはサポートしています。Mariaについてはに記述されています。

MySQL 6.0.11アルファ版は、とミラーサイトのダウンロード・ページから、多くのプラットフォーム用のソースコード及びバイナリで現在利用可能です。



MySQL 6.0の以前のバージョン以来の重要な変更、互換性のない変更、およびセキュリティ変更を以下のセクションに記載します。より多くの修正を含む全ての変更ログはで見ることができます。


   Functionality added or changed:

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

     * Replication: The global server variables sync_master_info and
       sync_relay_log_info are introduced for use on replication
       slaves to control synchronization of, respectively, the and 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
       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, "Replication
       Slave Options and Variables."

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

     * The MD5 algorithm now uses the Xfree implementation.

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

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

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

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

   Bugs fixed:

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

     * 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

          + A table that is being used by a transaction within one
            session cannot be used in DDL statements by other
            sessions until the transaction ends.

          + FLUSH TABLES WITH READ LOCK blocks for active
            transactions that hold metadata locks until those
            transactions end. The same is true for attempts to set
            the global value of the read_only system variable.

     * Important Change: Replication: CHANGE MASTER TO ...
       MASTER_HOST='' --- explicitly setting MASTER_HOST equal to an
       empty string --- created a 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.

     * 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.
       See alsoBug#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).

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

         1. A failure while allocating the master info structure
            caused the slave to crash.

         2. A failure during recovery caused the relay log file not
            to be properly initialized which led to a crash on the

     * Replication: Assigning an invalid directory for the
       --slave-load-tmpdir caused the replication slave to crash.

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

     * 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.
       See alsoBug#43046:
       This regression was introduced by

     * 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).
       See alsoBug#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
       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.

     * Replication: Server IDs greater than 2147483647 (2^32 - 1)
       were represented by negative numbers in the binary log.

     * 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:,

     * 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.
       See alsoBug#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:

         1. The error message Disk is full writing 'filename'
            (Errcode: error_code). Waiting for someone to free
            space... (Expect up to 60 secs delay for server to
            continue after freeing disk space) is printed only once.

         2. The warning Retry in 60 secs, Message reprinted in 600
            secs is printed once every for every 10 times that the
            check for free space is made; that is, the check is
            performed once each 60 seconds, but the reminder that
            space needs to be freed is printed only once every 10
            minutes (600 seconds).

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

     * The server could crash at startup when initializing plugins
       listed in the plugin table.

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

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

     * valgrind would report errors for the StorageInterface,
       StorageHAndler and CmdGen portions of Falcon.

     * On 64-bit debug builds, code in safemalloc resulted in errors
       due to use of a 32-bit value for 64-bit allocations.

     * When performing a high number of concurrent index updates on a
       Falcon table, mysqld could crash due to an assertion.

     * An attempt by a user who did not have the SUPER privilege to
       kill a system thread could cause a server crash.

     * On Windows, incorrectly specified link dependencies in
       CMakeLists.txt resulted in link errors for mysql_embedded,
       mysqltest_embedded, and mysql_client_test_embedded.

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

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

     * Running a SELECT using a range query on FLOAT on a Maria table
       could return invalid result sets.

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

     * Running a SELECT on a multi-range query with a LIMIT clause on
       a Maria table could return invalid result sets.

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

     * When performing SELECT statements on a Falcon table using an
       indexed INTEGER column could return incorrect row matches.

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

     * Use of USE INDEX hints could cause EXPLAIN EXTENDED to crash.

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

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

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

     * If the value of the version_comment system variable was too
       long, the mysql client displayed a truncated startup message.

     * Compilation failures on Windows Vista using Visual Studio 2008
       Professional were corrected.

     * Recovering a Falcon table from a failure when the table
       contains BLOB columns could cause an assertion failure.

     * On 32-bit Windows, mysqld could not use large buffers due to a
       2GB user mode address limit.

     * mysqld would crash when using Falcon tables during shutdown if
       the server was running in embedded mode.

     * The MySQL Backup library had incorrect logic and error
       reporting for metadata saving.

     * Queries of the following form returned an empty result:
       SELECT ... WHERE ... (col=col AND col=col) OR ...
       (false expression)

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

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

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

     * stderr should be unbuffered, but when the server redirected
       stderr to a file, it became buffered.

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

     * Recovery of Falcon tables while there were active transaction
       during the crash may fail to recover completely.

     * Use of semijoin optimization could cause a server crash.

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

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

     * When performing SELECT queries on tables containing TIMESTAMP
       or DATETIME colums with indexes using a WHERE clause comparing
       the field value to NULL using the <= or <> operators, the
       wrong information would be returned.

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

     * 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:

          + The server now supports an --ignore-builtin-innodb
            .html#option_mysqld_ignore-builtin-innodb) option that
            causes the server to behave as if the built-in InnoDB is
            not present. This option causes other InnoDB options not
            to be recognized.

          + For the INSTALL PLUGIN statement, the server reads option
            (my.cnf) files just as during server startup. This
            enables the plugin to pick up any relevant options from
            those files. Consequently, a plugin no longer is started
            with each option set to its default value.
            Because of this change, it is possible to add plugin
            options to an option file even before loading a plugin
            (if the loose prefix is used). It is also possible to
            uninstall a plugin, edit my.cnf, and install the plugin
            again. Restarting the plugin this way enables it to the
            new option values without a server restart.

       InnoDB Plugin versions 1.0.4 and higher will take advantage of
       this bug fix. Although the InnoDB Plugin is source code
       compatible with multiple MySQL releases, a given binary InnoDB
       Plugin can be used only with a specific MySQL release. When
       InnoDB Plugin 1.0.4 is released, it is expected to be compiled
       for MySQL 5.1.34. For 5.1.33, you can use InnoDB Plugin 1.0.3,
       but you must build from source.
       This regression was introduced by

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

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

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

     * Tables could enter open table cache for a thread without being
       properly cleaned up, leading to a server crash.

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

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

     * Recovery of Falcon tables with indexes can fail because the
       index page information has not been recorded properly.

     * Using a LIKE clause on a Maria table using an index and the
       CP1251 collation would return invalid data.

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

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

     * Using a falcon-scavenge-schedule of * * * * * would cause
       Falcon to never execute the required threads to operate.

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

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

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

     * In InnoDB recovery after a server crash, table lookup could
       fail and corrupt the data dictionary cache.

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

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

     * Recovering a Falcon table that uses BLOB columns could cause
       unbounded tablespace growth before recovery completes.

     * Recovery of Falcon tables could fail with an indicating that a
       wrong page type was identified in the Falcon serial log.

     * RESTORE crashed for Falcon tables.

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

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

     * The error message for a too-long column comment was Unknown
       error rather than a more appropriate message.

     * The Falcon CycleManager has been updated, which addresses a
       number of issues when examining records in various transaction
       states and their visisbility/isolation in relation to other
       threads. (Bug#41391:,

     * Use of SELECT * allowed users with rights to only some columns
       of a view to access all columns.

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

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

     * Several resource leaks were corrected in the error-handling
       code for the MySQL Backup library.

     * 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:,

     * SELECT statements executed concurrently with INSERT statements
       for a MyISAM table could cause incorrect results to be
       returned from the query cache.

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

     * For user-defined variables in a query result, incorrect length
       values were returned in the result metadata.

     * Using RESTORE to restore a database through a named pipe
       resulted in corrupt data.

     * Performing SELECT operations on Falcon tables using the
       maximum BIG INT value would fail to return matching rows.

     * For some queries, an equality propagation problem could cause
       a = b and b = a to be handled differently.

     * With strict SQL mode enabled, setting a system variable to an
       out-of-bounds value caused an assertion failure.

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

     * Indexes on Falcon tables using numeric columns could return
       incorrect information.

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

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

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

     * Falcon could cause an assertion when the system has run out of
       memory and tries to report the memory allocation failure.

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

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

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

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

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

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

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

     * If --basedir was specified, mysqld_safe did not use it when
       attempting to locate my_print_defaults.

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

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

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

     * BACKUP DATABASE treated the database list in case-sensitive
       fashion, even on case-insensitive file systems.

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

     * BACKUP DATABASE crashed if there was no default database.

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

     * Locking of myisam.log did not work correctly on Windows.

     * --help output for myisamchk did not list the --HELP option.

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

     * If a user created a view that referenced tables for which the
       user had disjoint privileges, an assertion failure occurred.

     * Trying to recover Falcon tables after a crash when the
       corresponding tables and tablespaces have not been created
       before the crash could cause a recovery failure.

     * When MySQL was configured with the --with-max-indexes=128
       option, mysqld crashed.

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

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

     * The use of NAME_CONST() can result in a problem for CREATE
       TABLE ... SELECT statements when the source column expressions
       refer to local variables. Converting these references to
       NAME_CONST() expressions can result in column names that are
       different on the master and slave servers, or names that are
       too long to be legal column identifiers. A workaround is to
       supply aliases for columns that refer to local variables.
       Now a warning is issued in such cases that indicate possible
       problems. (Bug#35383:

     * SHOW CREATE EVENT output did not include the DEFINER clause.

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

     * It was not possible to interrupt a long running BACKUP
       DATABASE or RESTORE operation.

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

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

     * A subquery using SELECT ... FOR UPDATE on a Falcon table fails
       to lock table correctly during the UPDATE.

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

     * INSTALL PLUGIN and UNINSTALL PLUGIN did not handle plugin
       identifiers consistently with respect to lettercase.

     * RESTORE often would not correctly identify the tablespace into
       which a Falcon table should be restored.

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

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

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

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

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

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

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

       erroneously reported a table to be corrupt if the table did
       not exist or the statement was terminated with KILL.

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

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

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

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

     * Incorrect length metadata could be returned for LONG TEXT
       columns when a multibyte server character set was used.

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