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


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

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


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


MySQL 5.1.37は、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#44270:http://bugs.mysql.com/44270)
     See alsoBug#34654:http://bugs.mysql.com/34654.

Bugs fixed:

   * Security Fix: Partitioning: Accessing a table with user-defined
     partitioning when the server SQL mode included ONLY_FULL_GROUP_BY
     caused the MySQL server to crash. For example, the following
     sequence of statements crashed the server:



     CREATE TABLE t1(id INT, key(id))


   * Important Change: Replication: When using STATEMENT or MIXED
     binary logging format, a statement that changes both
     non-transactional and transactional tables must be written to
     the binary log whenever there are changes to non-transactional
     tables. This means that the statement goes into the binary log
     even when the changes to the transactional tables fail. In
     particular, in the event of a failure such statement is
     annotated with the error number and wrapped inside a pair of
     BEGIN and ROLLBACK statements.
     On the slave, while applying the statement, it is expected
     that the same failure and the rollback prevent the
     transactional changes from persisting. However, statements
     that fail due to concurrency issues such as deadlocks and
     timeouts are logged in the same way, causing the slave to stop
     since the statements are applied sequentially by the SQL
     To address this issue, we ignore concurrency failures on the
     slave. Specifically, the following failures are now ignored:

   * Partitioning: Truncating a partitioned MyISAM table did not
     reset the AUTO_INCREMENT value.

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

   * Replication: Large transactions and statements could corrupt
     the binary log if the size of the cache (as set by
     max_binlog_cache_size) was not large enough to store the
     Now, for transactions that do not fit into the cache, the
     statement is not logged, and the statement generates an error
     For non-transactional changes that do not fit into the cache,
     the statement is also not logged --- an incident event is
     logged after committing or rolling back any pending
     transaction, and the statement then raises an error.

     If a failure occurs before the incident event is written the
     binary log, the slave does not stop, and the master does not
     report any errors.
     See alsoBug#37148:http://bugs.mysql.com/37148.

   * Replication: The --database option for mysqlbinlog was ignored
     when using the row-based logging format.

   * Replication: Shutting down the server while executing FLUSH
     LOGS, CHANGE MASTER TO, or STOP SLAVE could sometimes cause
     mysqld to crash. (Bug#38240:http://bugs.mysql.com/38240)

   * Replication: When reading a binary log that was in use by a
     master or that had not been properly closed (possibly due to a
     crash), the following message was printed: Warning: this
     binlog was not closed properly. Most probably mysqld crashed
     writing it. This message did not take into account the
     possibility that the file was merely in use by the master,
     which caused some users concern who were not aware that this
     could happen.
     To make this clear, the original message has been replaced
     with Warning: this binlog is either is use or was not closed
     properly. (Bug#34687:http://bugs.mysql.com/34687)

   * The server crashed if evaluation of GROUP_CONCAT(... ORDER BY)
     required allocation of a sort buffer but allocation failed.

   * When creating tables using the IBMDB2I storage engine with the
     ibmdb2i_create_index_option option set to 1, creating an
     IBMDB2I table with a primary key should produce an additional
     index that uses EBCDIC hexadecimal sorting, but this index was
     not created. (Bug#45983:http://bugs.mysql.com/45983)

   * With InnoDB tables, MySQL used a less-selective secondary
     index to avoid a filesort even if a prefix of the primary key
     was much more selective.
     The fix for this problem might cause other queries to run more
     slowly. (Bug#45828:http://bugs.mysql.com/45828)

   * The server crashed for attempts to use REPLACE or INSERT ...
     ON DUPLICATE KEY UPDATE with a view defined using a join.

   * Some collations were causing IBMDB2I to report inaccurate key
     range estimations to the optimizer for LIKE clauses that
     select substrings. This can be seen by running EXPLAIN. This
     problem primarily affects multi-byte and unicode character
     sets. (Bug#45803:http://bugs.mysql.com/45803)

   * Invalid memory reads and writes were generated when altering
     merge and base tables. This could lead to a crash or Valgrind
     ==28038== Invalid write of size 1
     at: memset (mc_replace_strmem.c:479)
     by: myrg_attach_children (myrg_open.c:433)
     by: ha_myisammrg::attach_children() (ha_myisammrg.cc:546)
     by: ha_myisammrg::extra(ha_extra_function) (ha_myisammrg.cc:944)
     by: attach_merge_children(TABLE_LIST*) (sql_base.cc:4147)
     by: open_tables(THD*, TABLE_LIST**, unsigned*, unsigned) (sql_base.cc
     by: open_and_lock_tables_derived(THD*, TABLE_LIST*, bool) (sql_base.c
     by: open_n_lock_single_table (mysql_priv.h:1550)
     by: mysql_alter_table(sql_table.cc:6428)
     by: mysql_execute_command(THD*) (sql_parse.cc:2860)
     by: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse
     by: dispatch_command (sql_parse.cc:1213)

   * Inserting data into a table using the macce character set with
     the IBMDB2I storage engine would fail.

   * There was a race condition when changing
     innodb_commit_concurrency at runtime to the value DEFAULT.
     See alsoBug#42101:http://bugs.mysql.com/42101.

   * Performing an empty XA transaction caused the server to crash
     for the next XA transaction.

   * For replication of a stored procedure that uses the gbk
     character set, the result on the master and slave differed.

   * SHOW CREATE TRIGGER requires the TRIGGER privilege but was not
     checking privileges. (Bug#45412:http://bugs.mysql.com/45412)

   * An assertion failure could occur if InnoDB tried to unlock a
     record when the clustered index record was unknown.

     --enable-plugin_name (for example, --enable-innodb) not to
     work. (Bug#45336:http://bugs.mysql.com/45336)

   * If autocommit was enabled, InnoDB did not roll back DELETE or
     UPDATE statements if the statement was killed.

   * Use of DECIMAL constants with more than 65 digits in CREATE
     TABLE ... SELECT statements led to spurious errors or
     assertion failures. (Bug#45262:http://bugs.mysql.com/45262)

   * The mysql client could misinterpret some character sequences
     as commands under some circumstances.

   * Use of CONVERT() with an empty SET value could cause an
     assertion failure. (Bug#45168:http://bugs.mysql.com/45168)

   * InnoDB recovery could hang due to redo logging of doublewrite
     buffer pages. (Bug#45097:http://bugs.mysql.com/45097)

   * when reading binary data, the concatenation function for
     geometry data collections did not rigorously check for
     available data, leading to invalid reads and server crashes.

   * If an error occurred during the creation of a table (for
     example, the table already existed) having an AUTO_INCREMENT
     column and a BEFORE trigger that used the INSERT ... SELECT
     construct, an internal flag was not reset properly. This led
     to a crash the next time that the table was opened again.

   * For queries with a sufficient number of subqueries in the FROM
     clause of this form:
     SELECT * FROM (SELECT 1) AS t1,
                   (SELECT 2) AS t2,
                   (SELECT 3) AS t3, ...
     The query failed with a Too high level of nesting for select
     error, as though the query had this form:

   * configure.in contained references to literal instances of nm
     and libc, rather than to variables parameterized for the
     proper values on the current platform.

   * configure.in did not properly check for the
     pthread_setschedprio() function.

   * A workaround for a Sun Studio bug was instituted.

   * Valgrind warnings that occurred for SHOW TABLE STATUS with
     InnoDB tables were silenced.

   * In the mysql client, if the server connection was lost during
     repeated status commands, the client would fail to detect this
     and command output would be inconsistent.

   * When invoked to start multiple server instances, mysqld_multi
     sometimes would fail to start them all due to not changing
     location into the base directory for each instance.

   * Renaming a column that appeared in a foreign key definition
     did not update the foreign key definition with the new column
     name. (Bug#21704:http://bugs.mysql.com/21704)