MySQL Community Server 5.1.62 がリリースされました


最も普及しているオープンソースデータベース管理システムの新バージョンMySQL Community Server 5.1.62がリリースされました。MySQL 5.1.62は、プロダクションシステムでの使用をお勧めします。

MySQL 5.1の新機能の概要については、以下を参照してください。


新たなサーバにMySQL 5.1.62をインストール、または以前のMySQLリリースからMySQL 5.1.61にアップグレードする際の情報については、以下を参照してください。







MySQL 5.1に関するオープンな問題の情報については、以下のエラッタリストを参照してください。





D.1.1. Changes in MySQL 5.1.62 (21 March, 2012)

    Functionality Added or Changed

      * yaSSL was upgraded from version 1.7.2 to 2.2.0.

    Bugs Fixed

      * Security Fix: Bug #13510739 and Bug #63775 were fixed.

      * Incompatible Change: An earlier change (in MySQL 5.1.59 and
        5.5.16) was found to modify date-handling behavior in General
        Availability-status series (MySQL 5.1 and 5.5). This change
        has been reverted.
        The change was that several functions became more strict when
        passed a DATE() function value as their argument, thus they
        rejected incomplete dates with a day part of zero. These
        functions were affected: CONVERT_TZ(), DATE_ADD(), DATE_SUB(),
        s.html#function_to-seconds), WEEK(), WEEKDAY(), WEEKOFYEAR(),
        YEARWEEK(). The previous behavior has been restored. (Bug

      * Important Change: InnoDB Storage Engine: When a row grew in
        size due to an UPDATE operation, other (non-updated) columns
        could be moved to off-page storage so that information about
        the row still fit within the constraints of the InnoDB page
        size. The pointer to the new allocated off-page data was not
        set up until the pages were allocated and written, potentially
        leading to lost data if the system crashed while the column
        was being moved out of the page. The problem was more common
        along with the Barracuda file format, particularly with the
        innodb_file_per_table setting enabled, because page allocation
        operations are more common as the .ibd tablespace files are
        extended. Still, the problem could occur with any combination
        of InnoDB version, file format, and row format.
        A related issue was that during such an UPDATE operation, or
        an INSERT operation that reused a delete-marked record, other
        transactions could see invalid data for the affected column,
        regardless of isolation level.
        The fix corrects the order of operations for moving the column
        data off the original page and replacing it with a pointer.
        Now if a crash occurs at the precise moment when the column
        data is being transferred, the transfer will not be re-run
        during crash recovery.
        In MySQL 5.1, this fix applies to the InnoDB Plugin, but not
        the built-in InnoDB storage engine. (Bug #13721257, Bug
        #12612184, Bug #12704861)

      * InnoDB Storage Engine: An erroneous assertion could occur, in
        debug builds only, when creating an index on a column
        containing zero-length values (that is, ''). (Bug #13654923)

      * InnoDB Storage Engine: A DDL operation such as ALTER TABLE ...
        ADD COLUMN could stall, eventually timing out with an Error
        1005: Can't create table message referring to
        fil_rename_tablespace. (Bug #13636122, Bug #62100, Bug #63553)

      * InnoDB Storage Engine: References to C preprocessor symbols
        and macros HAVE_purify, UNIV_INIT_MEM_TO_ZERO, and
        UNIV_SET_MEM_TO_ZERO were removed from the InnoDB source code.
        They were only used in debug builds instrumented for Valgrind.
        They are replaced by calls to the UNIV_MEM_INVALID() macro.
        (Bug #13418934)

      * InnoDB Storage Engine: A DDL operation for an InnoDB table
        could cause a busy MySQL server to halt with an assertion
InnoDB: Failing assertion: trx->error_state == DB_SUCCESS
        The error occurred if the DDL operation was run while all 1023
        undo slots were in use by concurrent transactions. This error
        was less likely to occur in MySQL 5.5 and 5.6, because raising
        the number of InnoDB undo slots increased the number of
        simultaneous transactions (corresponding to the number of undo
        slots) from 1K to 128K. (Bug #12739098, Bug #62401)

      * InnoDB Storage Engine: With 1024 concurrent InnoDB
        transactions running concurrently and the
        innodb_file_per_table setting enabled, a CREATE TABLE
        operation for an InnoDB table could fail. The .ibd file from
        the failed CREATE TABLE was left behind, preventing the table
        from being created later, after the load had dropped.
        The fix adds error handling to delete the erroneous .ibd file.
        This error was less likely to occur in MySQL 5.5 and 5.6,
        because raising the number of InnoDB undo slots increased the
        number of simultaneous transactions needed to trigger the bug,
        from 1K to 128K. (Bug #12400341)

      * InnoDB Storage Engine: When copying a partitioned InnoDB table
        from a Linux system to a Windows system, you could encounter
        this error:
101115 14:19:53 [ERROR] Table .\test\d has no primary key in InnoDB d
dictionary, but has one in MySQL!
        Normally, the solution to copy InnoDB tables from Linux to
        Windows is to create the tables on Linux with the
        lower_case_table_names option enabled. Partitioned tables,
        with #P# appended to the filename, were not covered by that
        solution. (Bug #11765438, Bug #58406)

      * InnoDB Storage Engine: Server startup could produce an error
        for temporary tables using the InnoDB storage engine, if the
        path in the $TMPDIR variable ended with a / character. The
        error log would look like:
120202 19:21:26  InnoDB: Operating system error number 2 in a file op
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
120202 19:21:26  InnoDB: Error: trying to open a table, but could not

InnoDB: open the tablespace file './t/#sql7750_1_0.ibd'!
InnoDB: Have you moved InnoDB .ibd files around without using the
InnoDB: It is also possible that this is a temporary table #sql...,
InnoDB: and MySQL removed the .ibd file for this.
        The workaround for the problem was to create a similar
        temporary table again, copy its .frm file to tmpdir under the
        name mentioned in the error message (for example, #sql123.frm)
        and restart mysqld with tmpdir set to its normal value without
        a trailing slash, for example /var/tmp. On startup, MySQL
        would see the .frm file and issue DROP TABLE for the orphaned
        temporary table. (Bug #11754376, Bug #45976)

      * A query that used an index on a CHAR column referenced in a
        BETWEEN clause could return invalid results. (Bug #13463488,
        Bug #63437)

      * When the optimizer performed conversion of DECIMAL values
        while evaluating range conditions, it could produce incorrect
        results. (Bug #13453382)

      * When used with the --xml option, mysqldump --routines failed
        to dump any stored routines, triggers, or events. (Bug
        #11760384, Bug #52792)

      * It was possible on replication slaves where FEDERATED tables
        were in use to get timeouts on long-running operations, such
        as Error 1160 Got an error writing communication packets. The
        FEDERATED tables did not need to be replicated for the issue
        to occur. (Bug #11758931, Bug #51196)
        References: See also Bug #12896628, Bug #61790.

      * If an attempt to initiate a statement failed, the issue could
        not be reported to the client because it was not prepared to
        receive any error messages prior to the execution of any
        statement. Since the user could not execute any queries, they
        were simply disconnected without providing a clear error.
        After the fix for this issue, the client is prepared for an
        error as soon as it attempts to initiate a statement, so that
        the error can be reported prior to disconnecting the user.
        (Bug #11755281, Bug #47032)

      * Using myisamchk with the sort recover method to repair a table
        having fixed-width row format could cause the row pointer size
        to be reduced, effectively resulting in a smaller maximum data
        file size. (Bug #48848, Bug #11756869)

      * Due to improper locking, concurrent inserts into an ARCHIVE
        table at the same time as repair and check operations on the
        table resulted in table corruption. (Bug #37280, Bug