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


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

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


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


MySQL 5.1.32は、http://dev.mysql.com/downloads/から、ソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。




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






Functionality added or changed:

  * 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:http://bugs.mysql.com/34654)

  * Incompatible Change: The fix for
   Bug#33699:http://bugs.mysql.com/33699introduced 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.

  * The libedit library was upgraded to version 2.11.

Bugs fixed:

  * Security Fix: Using an XPath expression employing a scalar
    expression as a FilterExpr
    (http://www.w3.org/TR/xpath#NT-FilterExpr) with ExtractValue()
    or UpdateXML() caused the server to crash. Such expressions
    now cause an error instead.

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

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

      1. An error was printed by InnoDB for TRUNCATE when using
         statement-based logging mode where the transaction
         isolation level was set to READ COMMITTED or READ
         UNCOMMITTED, because InnoDB permits statement-based
         replication for DML statements. However, TRUNCATE is not
         transactional; since it is the equivalent of DROP TABLE
         followed by CREATE TABLE, it is actually DDL, and should
         therefore be allowed to be replicated as a statement.

      2. TRUNCATE was not logged in mixed mode because of the
         error just described; however, this error was not
         reported to the client.

    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:http://bugs.mysql.com/36763)
    See alsoBug#42643:http://bugs.mysql.com/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).

  * Replication: In statement mode, mysqlbinlog failed to issue a
    SET @@autommit statement when the autocommit mode was changed.

  * 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:http://bugs.mysql.com/31240)

  * A '%' character in SQL statements could cause the server to
    crash. (Bug#42634:http://bugs.mysql.com/42634)

  * An optimization introduced for
   Bug#37553:http://bugs.mysql.com/37553required 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(...)).)

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

  * The SSL certficates included with MySQL distributions were
    regenerated because the previous ones had expired.

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

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

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

  * On Mac OS X, some of the universal client libraries were not
    actually universal and were missing code for one or more
    architectures. (Bug#41940:http://bugs.mysql.com/41940)

  * String reallocation could cause memory overruns.

  * 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:http://bugs.mysql.com/41671)

  * REPAIR TABLE crashed for compressed MyISAM tables.

  * 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:http://bugs.mysql.com/41370)

  * 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:http://bugs.mysql.com/41121)

  * FULLTEXT indexes did not work for Unicode columns that used a
    custom UCA collation. (Bug#41084:http://bugs.mysql.com/41084)

  * The Windows installer displayed incorrect product names in
    some images. (Bug#40845:http://bugs.mysql.com/40845)

  * SELECT statements could be blocked by INSERT DELAYED
    statements that were waiting for a lock, even with
    low_priority_updates enabled.

  * 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:http://bugs.mysql.com/40264)

  * When a MEMORY table became full, the error generated was
    returned to the client but was not written to the error log.

  * The expression ROW(...) IN (SELECT ... FROM DUAL) always
    returned TRUE. (Bug#39069:http://bugs.mysql.com/39069)

  * The greedy optimizer could cause a server crash due to
    improper handling of nested outer joins.

  * Use of COUNT(DISTINCT) prevented NULL testing in the HAVING
    clause. (Bug#38637:http://bugs.mysql.com/38637)

  * Enabling the sync_frm system variable had no effect on the
    handling of .frm files for views.

  * Setting myisam_repair_threads greater than 1 caused a server
    crash for table repair or alteration operations for MyISAM
    tables with multiple FULLTEXT indexes.

  * The mysql client sometimes improperly interpreted string
    escape sequences in non-string contexts.

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

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

  * libmysqld was not built with all character sets.

  * 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:http://bugs.mysql.com/32136)

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

  * If the default database was dropped, the value of
    character_set_database was not reset to character_set_server
    as it should have been.