MySQL 5.5.8 がリリースされました


世界でもっともポピュラーなオープンソースデータベースの最初の5.5のプロダクトバージョンであるMySQL Server 5.5.8 GAがリリースをアナウンスします。MySQL 5.5.8はプロダクションシステムでの仕様をお勧めします。

MySQL 5.5はMySQLサーバのスケーラビリティとパフォーマンス問題に対処するための影響の大きい変更をいくつか含んでいます。これらの変更はハードウェア とCPUデザインのメリットを有効に利用し、既存ハードウェアの利用率を高めます。MySQL 5.5は以下の多くの新しい強化も含んでいます:

   - InnoDBのI/Oサブシステムの変更

   - Solarisサポートの強化

   - 性能の診断とモニタリング

詳細は、オンラインの"MySQL 5.5の新機能"の節を確認してください。


製品レベルのシステムでMySQLを稼動させているならば、MySQL Enterprise Editionの製品詳細に注目してください:


新しいサーバへMySQL 5.5.8をインストールする情報として、以下のMySQLのインストールドキュメントを参照してください。





MySQL Server 5.5は、http://dev.mysql.com/downloads/とミラーサイトのダウンロード・ページから、ソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。




次の節では、MySQL 5.5の以前のバージョンからのMySQLソースコードの変更を記載しています。これはオンラインでも閲覧できます。

D.1.1. Changes in MySQL 5.5.8 (03 December 2010)

    Configuration Notes:

      * MySQL releases are now built on all platforms using CMake
        rather than the GNU autotools, so autotools support has been
        removed. For instructions on building MySQL with CMake, see
        Section 2.11, "Installing MySQL from Source." Third-party
        tools that need to extract the MySQL version number formerly
        found in configure.in can use the VERSION file. See Section
        2.11.6, "MySQL Configuration and Third-Party Tools."

    Functionality added or changed:

      * Support for the IBMDB2I storage engine has been removed.
        (<a href="http://bugs.mysql.com/58079">Bug#58079</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=58079">http://bugs.mysql.com/bug.php?id=58079</a>)

      * A --bind-address option has been added to a number of MySQL
        client programs: mysql, mysqldump, mysqladmin, mysqlbinlog,
        mysqlcheck, mysqlimport, and mysqlshow. This is for use on a
        computer having multiple network interfaces, and enables you
        to choose which interface is used to connect to the MySQL

    Bugs fixed:

      * Performance: InnoDB Storage Engine: Improved concurrency when
        several ANALYZE TABLE or SHOW TABLE STATUS statements are run
        simultaneously for InnoDB tables.
        (<a href="http://bugs.mysql.com/53046">Bug#53046</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=53046">http://bugs.mysql.com/bug.php?id=53046</a>)

      * Incompatible Change: Previously, tables in the
        performance_schema database had uppercase names. This was
        incompatible with the lower_case_table_names system variable,
        and caused issues when the variable value was changed after
        installing or upgrading.
        Now performance_schema table names are lowercase, so they
        appear in uniform lettercase regardless of the
        lower_case_table_names setting. References to these tables in
        SQL statements should be given in lowercase. This is an
        incompatible change, but provides compatible behavior across
        different values of lower_case_table_names.
        If you upgrade to MySQL 5.5.8 from an earlier version of MySQL
        5.5, be sure to run mysql_upgrade (and restart the server) to
        change the names of existing performance_schema tables from
        uppercase to lowercase.
        (<a href="http://bugs.mysql.com/57609">Bug#57609</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57609">http://bugs.mysql.com/bug.php?id=57609</a>)

      * Incompatible Change: The following changes were made to the
        performance_schema.threads table for conformance with the
        implementation in MySQL 5.6:

           + ID column: Renamed to PROCESSLIST_ID, removed NOT NULL
             from definition.

           + NAME column: Changed from VARCHAR(64) to VARCHAR(128).
        (<a href="http://bugs.mysql.com/57154">Bug#57154</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57154">http://bugs.mysql.com/bug.php?id=57154</a>)

      * Incompatible Change: Deadlock occurred when a connection that
        had some table open through a HANDLER statement tried to
        update data through a DML statement while another connection
        tried to execute FLUSH TABLES WITH READ LOCK concurrently.
        Starvation of FLUSH TABLES WITH READ LOCK statements occurred
        when there was a constant load of concurrent DML statements in
        two or more connections.
        These problems resulted from the global read lock
        implementation, which was reimplemented with the following

           + To solve deadlock in event-handling code that was exposed
             by this patch, the LOCK_event_metadata mutex was replaced
             with metadata locks on events. As a result, DDL operations
             on events are now prohibited under LOCK TABLES. This is
             an incompatible change.

           + The global read lock (FLUSH TABLES WITH READ LOCK) no
             longer blocks DML and DDL on temporary tables. Before
             this patch, server behavior was not consistent in this
             respect: In some cases, DML/DDL statements on temporary
             tables were blocked; in others, they were not. Since the
             main use cases for FLUSH TABLES WITH READ LOCK are
             various forms of backups and temporary tables are not
             preserved during backups, the server now consistently
             allows DML/DDL on temporary tables under the global read

           + Thread state names are now either Waiting for global read
             lock or Waiting for commit lock, depending on which stage
             FLUSH TABLES WITH READ LOCK is in.
        (<a href="http://bugs.mysql.com/57006">Bug#57006</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57006,">http://bugs.mysql.com/bug.php?id=57006,</a>
        <a href="http://bugs.mysql.com/54673">Bug#54673</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=54673">http://bugs.mysql.com/bug.php?id=54673</a>)

      * InnoDB Storage Engine: Values could be truncated in certain
        INFORMATION_SCHEMA columns, such as
        (<a href="http://bugs.mysql.com/57960">Bug#57960</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57960">http://bugs.mysql.com/bug.php?id=57960</a>)

      * InnoDB Storage Engine: For an InnoDB table created with
        ROW_FORMAT=COMPRESSED or ROW_FORMAT=DYNAMIC, a query using the
        READ UNCOMMITTED isolation level could cause the server to
        stop with an assertion error, if BLOB or other large columns
        that use off-page storage were being inserted at the same
        time. (<a href="http://bugs.mysql.com/57799">Bug#57799</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57799">http://bugs.mysql.com/bug.php?id=57799</a>)

      * InnoDB Storage Engine: The server could stop with an assertion
        error on Windows Vista and Windows 7 systems.
        (<a href="http://bugs.mysql.com/57720">Bug#57720</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57720">http://bugs.mysql.com/bug.php?id=57720</a>)

      * InnoDB Storage Engine: A followup fix to
        <a href="http://bugs.mysql.com/54678">Bug#54678</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=54678">http://bugs.mysql.com/bug.php?id=54678</a>. TRUNCATE
        TABLE could still cause a crash (assertion error) in the
        debug version of the server.
        (<a href="http://bugs.mysql.com/57700">Bug#57700</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57700">http://bugs.mysql.com/bug.php?id=57700</a>)

      * InnoDB Storage Engine: The InnoDB system tablespace could grow
        continually for a server under heavy load.
        (<a href="http://bugs.mysql.com/57611">Bug#57611</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57611">http://bugs.mysql.com/bug.php?id=57611</a>)

      * InnoDB Storage Engine: Heavy concurrent updates of a BLOB
        column in an InnoDB table could cause a hang.
        (<a href="http://bugs.mysql.com/57579">Bug#57579</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57579">http://bugs.mysql.com/bug.php?id=57579</a>)

      * InnoDB Storage Engine: The innodb_stats_on_metadata option
        could prevent the ANALYZE TABLE statement from running.
        (<a href="http://bugs.mysql.com/57252">Bug#57252</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57252">http://bugs.mysql.com/bug.php?id=57252</a>)

      * InnoDB Storage Engine: A query for an InnoDB table could
        return the wrong value if a column value was changed to a
        different case, and the column had a case-insensitive index.
        (<a href="http://bugs.mysql.com/56680">Bug#56680</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=56680">http://bugs.mysql.com/bug.php?id=56680</a>)

      * InnoDB Storage Engine: An existing InnoDB could be switched to
        ROW_FORMAT=COMPRESSED implicitly by a KEY_BLOCK_SIZE clause in
        an ALTER TABLE statement. Now, the row format is only switched
        to compressed if there is an explicit ROW_FORMAT=COMPRESSED
        clause. on the ALTER TABLE statement.
        Any valid, non-default ROW_FORMAT parameter takes precedence
        over KEY_BLOCK_SIZE when both are specified. KEY_BLOCK_SIZE
        only enables ROW_FORMAT=COMPRESSED if ROW_FORMAT is not
        specified on either the CREATE TABLE or ALTER TABLE statement,
        or is specified as DEFAULT. In case of a conflict between
        KEY_BLOCK_SIZE and ROW_FORMAT clauses, the KEY_BLOCK_SIZE is
        ignored if innodb_strict_mode is off, and the statement causes
        an error if innodb_strict_mode is on.
        (<a href="http://bugs.mysql.com/56632">Bug#56632</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=56632">http://bugs.mysql.com/bug.php?id=56632</a>)

      * InnoDB Storage Engine: The clause KEY_BLOCK_SIZE=0 is now
        allowed on CREATE TABLE and ALTER TABLE statements for InnoDB
        tables, regardless of the setting of innodb_strict_mode. The
        zero value has the effect of resetting the KEY_BLOCK_SIZE
        table parameter to its default value, depending on the
        ROW_FORMAT parameter, as if it had not been specified. That
        default is 8 if ROW_FORMAT=COMPRESSED. Otherwise,
        KEY_BLOCK_SIZE is not used or stored with the table
        As a consequence of this fix, ROW_FORMAT=FIXED is not allowed
        when the innodb_strict_mode is enabled.
        (<a href="http://bugs.mysql.com/56628">Bug#56628</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=56628">http://bugs.mysql.com/bug.php?id=56628</a>)

      * InnoDB Storage Engine: A large number of foreign key
        declarations could cause the output of the SHOW CREATE
        STATEMENT statement to be truncated.
        (<a href="http://bugs.mysql.com/56143">Bug#56143</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=56143">http://bugs.mysql.com/bug.php?id=56143</a>)

      * InnoDB Storage Engine: A compilation problem affected the
        InnoDB source code on NetBSD/sparc64.
        (<a href="http://bugs.mysql.com/53916">Bug#53916</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=53916">http://bugs.mysql.com/bug.php?id=53916</a>)

      * InnoDB Storage Engine: Clarified the message when a CREATE
        TABLE statement fails because a foreign key constraint does
        not have the required indexes.
        (<a href="http://bugs.mysql.com/16290">Bug#16290</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=16290">http://bugs.mysql.com/bug.php?id=16290</a>)

     * Partitioning: "Fast" ALTER TABLE operations (that do not
        involve a table copy) on a partitioned table could leave the
        table in an unusable state.
        (<a href="http://bugs.mysql.com/57985">Bug#57985</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57985">http://bugs.mysql.com/bug.php?id=57985</a>)

      * Partitioning: An INSERT ... ON DUPLICATE KEY UPDATE column = 0
        statement on an AUTO_INCREMENT column caused the debug server
        to crash. (<a href="http://bugs.mysql.com/57890">Bug#57890</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57890">http://bugs.mysql.com/bug.php?id=57890</a>)

      * Replication: Concurrent statements using a stored function and
        a DROP DATABASE statement that caused the same stored function
        to be dropped could cause statement-based replication to fail.
        This problem is resolved by making sure that DROP DATABASE
        takes an exclusive metadata lock on all stored functions and
        stored procedures that it causes to be dropped.
        (<a href="http://bugs.mysql.com/57663">Bug#57663</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57663">http://bugs.mysql.com/bug.php?id=57663</a>)
        See also <a href="http://bugs.mysql.com/30977">Bug#30977</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=30977">http://bugs.mysql.com/bug.php?id=30977</a>.

      * Replication: When STOP SLAVE is issued, the slave SQL thread
        rolls back the current transaction and stops immediately if
        the transaction updates only tables which use transactional
        storage engines are updated. Previously, this occurred even
        when the transaction contained CREATE TEMPORARY TABLE
        statements, DROP TEMPORARY TABLE statements, or both, although
        these statements cannot be rolled back. Because temporary
        tables persist for the lifetime of a user session (in the
        case, the replication user), they remain until the slave is
        stopped or reset. When the transaction is restarted following
        a subsequent START SLAVE statement, the SQL thread aborts with
        an error that a temporary table to be created (or dropped)
        already exists (or does not exist, in the latter case).
        Following this fix, if an ongoing transaction contains CREATE
        TEMPORARY TABLE statements, DROP TEMPORARY TABLE statements,
        or both, the SQL thread now waits until the transaction ends,
        then stops.
        (<a href="http://bugs.mysql.com/56118">Bug#56118</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=56118">http://bugs.mysql.com/bug.php?id=56118</a>)

      * Replication: If there exist both a temporary table and a
        non-temporary table having the same, updates normally apply
        only to the temporary table, with the exception of a CREATE
        TABLE ... SELECT statement that creates a non-temporary table
        having the same name as an existing temporary table. When such
        a statement was replicated using the MIXED logging format, and
        the statement was unsafe for row-based logging, updates were
        misapplied to the temporary table.
        Updates were also applied wrongly when a temporary table that
        used a transactional storage engine was dropped inside a
        transaction, followed by updates within the same transaction
        to a non-temporary table having the same name.
        (<a href="http://bugs.mysql.com/55478">Bug#55478</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=55478">http://bugs.mysql.com/bug.php?id=55478</a>)
        See also <a href="http://bugs.mysql.com/47899">Bug#47899</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=47899,">http://bugs.mysql.com/bug.php?id=47899,</a>
        <a href="http://bugs.mysql.com/55709">Bug#55709</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=55709">http://bugs.mysql.com/bug.php?id=55709</a>.

      * Replication: When making changes to relay log settings using
        CHANGE MASTER TO, the I/O cache was not cleared. This could
        result in replication failure when the slave attempted to read
        stale data from the cache and then stopped with an assertion.
        (<a href="http://bugs.mysql.com/55263">Bug#55263</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=55263">http://bugs.mysql.com/bug.php?id=55263</a>)

      * Replication: Replication of SET and ENUM columns represented
        using more than 1 byte (that is, SET columns with more than 8
        members and ENUM columns with more than 256 constants) between
        platforms using different endianness failed when using the
        row-based format. This was because columns of these types are
        represented internally using integers, but the internal
        functions used by MySQL to handle them treated them as
        strings. (<a href="http://bugs.mysql.com/52131">Bug#52131</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=52131">http://bugs.mysql.com/bug.php?id=52131</a>)
        See also <a href="http://bugs.mysql.com/53528">Bug#53528</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=53528">http://bugs.mysql.com/bug.php?id=53528</a>.

      * Replication: Trying to read from a binary log containing a log
        event of an invalid type caused the slave to crash.
        (<a href="http://bugs.mysql.com/38718">Bug#38718</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=38718">http://bugs.mysql.com/bug.php?id=38718</a>)

      * Replication: When replicating the mysql.tables_priv table, the
        Grantor column was not replicated, and was thus left empty on
        the slave. (<a href="http://bugs.mysql.com/27606">Bug#27606</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=27606">http://bugs.mysql.com/bug.php?id=27606</a>)

      * Setting the read_only system variable at server startup did
        not work. (<a href="http://bugs.mysql.com/58669">Bug#58669</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=58669">http://bugs.mysql.com/bug.php?id=58669</a>)

      * mysql_upgrade failed after an upgrade from MySQL 5.1.
        (<a href="http://bugs.mysql.com/58514">Bug#58514</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=58514">http://bugs.mysql.com/bug.php?id=58514</a>)

      * When configuring the build with -DBUILD_CONFIG=mysql_release
        and building with Visual Studio Express, the build failed if
        signtool.exe was not present.
        (<a href="http://bugs.mysql.com/58313">Bug#58313</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=58313">http://bugs.mysql.com/bug.php?id=58313</a>)

      * When configuring the build with -DBUILD_CONFIG=mysql_release
        on Linux, libaio is required, but the error message if it was
        missing was uninformative.
        (<a href="http://bugs.mysql.com/58227">Bug#58227</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=58227">http://bugs.mysql.com/bug.php?id=58227</a>)

      * Use of NAME_CONST() in a HAVING clause caused a server crash.
        (<a href="http://bugs.mysql.com/58199">Bug#58199</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=58199">http://bugs.mysql.com/bug.php?id=58199</a>)

      * BETWEEN did not use indexes for DATE or DATETIME columns.
        (<a href="http://bugs.mysql.com/58190">Bug#58190</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=58190">http://bugs.mysql.com/bug.php?id=58190</a>)

      * Memory was allocated in fn_expand() for storing path names,
        but not freed anywhere.
        (<a href="http://bugs.mysql.com/58173">Bug#58173</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=58173">http://bugs.mysql.com/bug.php?id=58173</a>)

      * In debug builds, inserting a FLOAT value into a CHAR(0) column
        could crash the server.
        (<a href="http://bugs.mysql.com/58137">Bug#58137</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=58137">http://bugs.mysql.com/bug.php?id=58137</a>)

      * Failure to create a thread to handle a user connection could
        result in a server crash.
        (<a href="http://bugs.mysql.com/58080">Bug#58080</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=58080">http://bugs.mysql.com/bug.php?id=58080</a>)

      * During configuration, ADD_VERSION_INFO in
        cmake/mysql_version.cmake failed if LINK_FLAGS was modified.
        (<a href="http://bugs.mysql.com/58074">Bug#58074</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=58074">http://bugs.mysql.com/bug.php?id=58074</a>)

      * Performance Schema did not account for I/O for the binary log
        file (no I/O was counted).
        (<a href="http://bugs.mysql.com/58052">Bug#58052</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=58052">http://bugs.mysql.com/bug.php?id=58052</a>)

      * Several compilation problems were fixed.
        (<a href="http://bugs.mysql.com/57992">Bug#57992</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57992,">http://bugs.mysql.com/bug.php?id=57992,</a>
        <a href="http://bugs.mysql.com/57993">Bug#57993</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57993,">http://bugs.mysql.com/bug.php?id=57993,</a>
        <a href="http://bugs.mysql.com/57994">Bug#57994</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57994,">http://bugs.mysql.com/bug.php?id=57994,</a>
        <a href="http://bugs.mysql.com/57995">Bug#57995</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57995,">http://bugs.mysql.com/bug.php?id=57995,</a>
        <a href="http://bugs.mysql.com/57996">Bug#57996</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57996,">http://bugs.mysql.com/bug.php?id=57996,</a>
        <a href="http://bugs.mysql.com/57997">Bug#57997</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57997,">http://bugs.mysql.com/bug.php?id=57997,</a>
        <a href="http://bugs.mysql.com/58057">Bug#58057</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=58057">http://bugs.mysql.com/bug.php?id=58057</a>)

      * After creating a table with two foreign key constraints, the
        only one of them.
        (<a href="http://bugs.mysql.com/57904">Bug#57904</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57904">http://bugs.mysql.com/bug.php?id=57904</a>)

      * Incorrect error handling raised an assertion if character set
        conversion wrapped an item that failed.
        (<a href="http://bugs.mysql.com/57882">Bug#57882</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57882">http://bugs.mysql.com/bug.php?id=57882</a>)

      * In debug builds, a missing DBUG_RETURN macro in sql/client.c
        caused mysql to be unable to connect to the server.
        (<a href="http://bugs.mysql.com/57744">Bug#57744</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57744">http://bugs.mysql.com/bug.php?id=57744</a>)

      * Clients using a client library older than MySQL 5.5.7 suffered
        loss of connection after executing mysql_change_user() while
        connected to a 5.5.7 server.
        (<a href="http://bugs.mysql.com/57689">Bug#57689</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57689">http://bugs.mysql.com/bug.php?id=57689</a>)

      * The MySQL-shared RPM package failed to provide the lowercase
        virtual identifier 'mysql-shared' in the RPM 'Provides' tags
        (usually used for backward compatibility).
        (<a href="http://bugs.mysql.com/57596">Bug#57596</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57596">http://bugs.mysql.com/bug.php?id=57596</a>)

      * For an upgrade to MySQL 5.5.7 from a previous release, the
        server exited if the mysql.proxies_priv table did not exist,
        making upgrades inconvenient. Now the server treats a missing
        proxies_priv table as equivalent to an empty table. However,
        after starting the server, you should still run mysql_upgrade
        to create the table.
        (<a href="http://bugs.mysql.com/57551">Bug#57551</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57551">http://bugs.mysql.com/bug.php?id=57551</a>)

      * SHOW PROCESSLIST displayed non-ASCII characters improperly.
        (<a href="http://bugs.mysql.com/57306">Bug#57306</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57306">http://bugs.mysql.com/bug.php?id=57306</a>)

      * Passing a string that was not null-terminated to UpdateXML()
        or ExtractValue() caused the server to fail with an assertion.
        (<a href="http://bugs.mysql.com/57279">Bug#57279</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57279">http://bugs.mysql.com/bug.php?id=57279</a>)

      * SET GLOBAL debug could cause a crash on Solaris if the server
        failed to open the trace file.
        (<a href="http://bugs.mysql.com/57274">Bug#57274</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57274">http://bugs.mysql.com/bug.php?id=57274</a>)

      * In debug builds, an assertion could be raised during
        conversion of strings to floating-point values.
        (<a href="http://bugs.mysql.com/57203">Bug#57203</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57203">http://bugs.mysql.com/bug.php?id=57203</a>)

      * A user with no privileges on a stored routine or the
        mysql.proc table could discover the routine's existence.
        (<a href="http://bugs.mysql.com/57061">Bug#57061</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=57061">http://bugs.mysql.com/bug.php?id=57061</a>)

      * Queries executed using the Index Merge access method and a
        temporary file could return incorrect results.
        (<a href="http://bugs.mysql.com/56862">Bug#56862</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=56862">http://bugs.mysql.com/bug.php?id=56862</a>)

      * The server could crash as a result of accessing freed memory
        when populating INFORMATION_SCHEMA.VIEWS if a view could not
        be opened properly.
        (<a href="http://bugs.mysql.com/56540">Bug#56540</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=56540">http://bugs.mysql.com/bug.php?id=56540</a>)

      * Valgrind warnings about overlapping memory when
        double-assigning the same variable were corrected.
        (<a href="http://bugs.mysql.com/56138">Bug#56138</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=56138">http://bugs.mysql.com/bug.php?id=56138</a>)

      * If a STOP SLAVE statement was issued while the slave SQL
        thread was executing a statement that invoked the SLEEP()
        function, both statements hung.
        (<a href="http://bugs.mysql.com/56096">Bug#56096</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=56096">http://bugs.mysql.com/bug.php?id=56096</a>)

      * OPTIMIZE TABLE for InnoDB tables could raise an assertion.
        (<a href="http://bugs.mysql.com/55930">Bug#55930</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=55930">http://bugs.mysql.com/bug.php?id=55930</a>)

      * Warnings raised by a trigger were not cleared upon successful
        completion. Now warnings are cleared if the trigger completes
        successfully, per the SQL standard.
        (<a href="http://bugs.mysql.com/55850">Bug#55850</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=55850">http://bugs.mysql.com/bug.php?id=55850</a>)

      * For CMake builds, some parts of the source were unnecessarily
        compiled twice if the embedded server was built.
        (<a href="http://bugs.mysql.com/55647">Bug#55647</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=55647">http://bugs.mysql.com/bug.php?id=55647</a>)

      * Boolean command options caused an error if given with an
        option value and the loose- option prefix.
        (<a href="http://bugs.mysql.com/54569">Bug#54569</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=54569">http://bugs.mysql.com/bug.php?id=54569</a>)

      * An error in a stored procedure could leave the session in a
        different default database.
        (<a href="http://bugs.mysql.com/54375">Bug#54375</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=54375">http://bugs.mysql.com/bug.php?id=54375</a>)

      * The CMake "wrapper" for configure (configure.pl) did not
        handle the --with-comment option properly.
        (<a href="http://bugs.mysql.com/52275">Bug#52275</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=52275">http://bugs.mysql.com/bug.php?id=52275</a>)

      * Grouping by a TIME_TO_SEC() function result could cause a
        server crash or incorrect results. Grouping by a function
        returning a BLOB could cause an unexpected "Duplicate entry"
        error and incorrect result.
        (<a href="http://bugs.mysql.com/52160">Bug#52160</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=52160">http://bugs.mysql.com/bug.php?id=52160</a>)

      * The find_files() function used by SHOW statements performed
        redundant and unnecessary memory allocation.
        (<a href="http://bugs.mysql.com/51208">Bug#51208</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=51208">http://bugs.mysql.com/bug.php?id=51208</a>)

      * The Windows sample option files contained values more
        appropriate for Linux.
        (<a href="http://bugs.mysql.com/50021">Bug#50021</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=50021">http://bugs.mysql.com/bug.php?id=50021</a>)

      * A failed RENAME TABLE operation could prevent a FLUSH TABLES
        WITH READ LOCK from completing.
        (<a href="http://bugs.mysql.com/47924">Bug#47924</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=47924">http://bugs.mysql.com/bug.php?id=47924</a>)

      * Error messages for several internal conditions that should not
        occur were changed to instruct the user to file a bug if they
        do occur. (<a href="http://bugs.mysql.com/47027">Bug#47027</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=47027">http://bugs.mysql.com/bug.php?id=47027</a>)

      * On file systems with case insensitive file names, and
        lower_case_table_names=2, the server could crash due to a
        table definition cache inconsistency.
        (<a href="http://bugs.mysql.com/46941">Bug#46941</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=46941">http://bugs.mysql.com/bug.php?id=46941</a>)

      * Handling of host name lettercase in GRANT statements was
        (<a href="http://bugs.mysql.com/36742">Bug#36742</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=36742">http://bugs.mysql.com/bug.php?id=36742</a>)

      * SET NAMES utf8 COLLATE utf8_sinhala_ci did not work.
        (<a href="http://bugs.mysql.com/26474">Bug#26474</a>: <a rel="nofollow" href="http://bugs.mysql.com/bug.php?id=26474">http://bugs.mysql.com/bug.php?id=26474</a>)

      * The utf16_bin collation uses code-point order, not
        byte-by-byte order, as described at Section, "Unicode
        Character Sets." (The order was byte-by-byte in MySQL 5.5.7.)