MySQLニュース

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

オリジナル版:http://dev.mysql.com/doc/refman/5.1/en/news-5-1-43.html


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

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

 http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html


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

  http://dev.mysql.com/doc/refman/5.1/en/installing.html


MySQLサーバは、http://dev.mysql.com/downloads/から、ソースコード及び多数のプラットフォーム用バイナリが入手可能です。

現時点ですべてのミラーサイトが最新であるとは限らないことに注意してください。
あるミラーサイトで本バージョンを見つけることができない場合は、後日再確認を行うか、別のダウンロード・サイトを選択してください。


バグレポート、バグ修正、パッチ等の情報をお待ちしておりますので、以下のページをご利用ください。

http://forge.mysql.com/wiki/Contributing


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

 http://dev.mysql.com/doc/refman/5.1/en/open-bugs.html


以下のセクションはMySQL5.1の前リリース以降のMySQLソースコードの変更を記載しています。これはオンラインでも閲覧可能です:

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-42.html

以下は、追加または変更された機能です。

=======================================================================

C.1.2. Changes in MySQL 5.1.43

InnoDB Plugin Notes:

* This release includes InnoDB Plugin 1.0.6. This version is
considered of Release Candidate (RC) quality.

Functionality added or changed:

* Partitioning: The UNIX_TIMESTAMP() function is now supported
in partitioning expressions using TIMESTAMP columns. For
example, it now possible to create a partitioned table such as
this one:
CREATE TABLE t (c TIMESTAMP)
PARTITION BY RANGE ( UNIX_TIMESTAMP(c) ) (
PARTITION p0 VALUES LESS THAN (631148400),
PARTITION p1 VALUES LESS THAN (946681200),
PARTITION p2 VALUES LESS THAN (MAXVALUE)
);
All other expressions involving TIMESTAMP values are now
rejected with an error when attempting to create a new
partitioned table or to alter an existing partitioned table.
When accessing an existing partitioned table having a
timezone-dependent partitioning function (where the table was
using a previous version of MySQL), a warning rather than an
error is issued. In such cases, you should fix the table. One
way of doing this is to alter the table's partitioning
expression so that it uses UNIX_TIMESTAMP().
(Bug#42849: http://bugs.mysql.com/bug.php?id=42849)

Bugs fixed:

* Security Fix: For servers built with yaSSL, a preauthorization
buffer overflow could cause memory corruption or a server
crash. We thank Evgeny Legerov from Intevydis for providing us
with a proof-of-concept script that allowed us to reproduce
this bug. (Bug#50227: http://bugs.mysql.com/bug.php?id=50227,
CVE-2009-4484
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4484))

* Important Change: Replication: The RAND() function is now
marked as unsafe for statement-based replication. Using this
function now generates a warning when binlog_format=STATEMENT
and causes the the format to switch to row-based logging when
binlog_format=MIXED.
This change is being introduced because, when RAND() was
logged in statement mode, the seed was also written to the
binary log, so the replication slave generated the same
sequence of random numbers as was generated on the master.
While this could make replication work in some cases, the
order of affected rows was still not guaranteed when this
function was used in statements that could update multiple
rows, such as UPDATE or INSERT ... SELECT; if the master and
the slave retrieved rows in different order, they began to
diverge. (Bug#49222: http://bugs.mysql.com/bug.php?id=49222)

* Partitioning: When used on partitioned tables, the
records_in_range handler call checked all partitions, rather
than the unpruned partitions only.
(Bug#48846: http://bugs.mysql.com/bug.php?id=48846)
See also Bug#37252: http://bugs.mysql.com/bug.php?id=37252,
Bug#47261: http://bugs.mysql.com/bug.php?id=47261.

* Partitioning: A query that searched on a ucs2 column failed if
the table was partitioned.
(Bug#48737: http://bugs.mysql.com/bug.php?id=48737)

* Replication: A LOAD DATA INFILE statement that loaded data
into a table having a column name that must be escaped (such
as `key` INT), caused replication to fail when logging in
mixed or statement mode. In such cases, the master wrote the
LOAD DATA event to the binary log without escaping the field
names. (Bug#49473: http://bugs.mysql.com/bug.php?id=49473)
See also Bug#47927: http://bugs.mysql.com/bug.php?id=47927.

* Replication: Spatial data types cause row-based replication to
crash. (Bug#48776: http://bugs.mysql.com/bug.php?id=48776)

* Replication: A flaw in the implementation of the purging of
binary logs could result in orphaned files being left behind
in the following circumstances:

+ If the server failed or was killed while purging binary
logs.
If the server failed or was killed after creating of a
new binary log when the new log file was opened for the
first time.
In addition, if the slave was not connected during the purge
operation, it was possible for a log file that was in use to
be removed; this could lead data loss and possible
inconsistencies between the master and slave.
(Bug#45292: http://bugs.mysql.com/bug.php?id=45292)

* Replication: When using the STATEMENT or MIXED logging format,
the statements LOAD DATA CONCURRENT LOCAL INFILE and LOAD DATA
CONCURRENT INFILE were logged as LOAD DATA LOCAL INFILE and
LOAD DATA LOCAL INFILE, respectively (in other words, the
CONCURRENT keyword was omitted). As a result, when using
replication with either of these logging modes, queries on the
slaves were blocked by the replication SQL thread while trying
to execute the affected statements.
(Bug#34628: http://bugs.mysql.com/bug.php?id=34628)

* Replication: Manually removing entries from the binary log
index file on a replication master could cause the server to
repeatedly send the same binary log file to slaves.
(Bug#28421: http://bugs.mysql.com/bug.php?id=28421)

* Cluster Replication: When expire_logs_days was set, the thread
performing the purge of the log files could deadlock, causing
all binary log operations to stop.
(Bug#49536: http://bugs.mysql.com/bug.php?id=49536)

* Within a stored routine, selecting the result of CONCAT_WS()
with a routine parameter argument into a user variable could
return incorrect results.
(Bug#50096: http://bugs.mysql.com/bug.php?id=50096)

* The IBMDB2I storage engine was missing from the i5os 64-bit
distribution of MySQL 5.1.42. It is now included again.
(Bug#50059: http://bugs.mysql.com/bug.php?id=50059)

* EXPLAIN EXTENDED UNION ... ORDER BY caused a crash when the
ORDER BY referred to a nonconstant or full-text function or a
subquery. (Bug#49734: http://bugs.mysql.com/bug.php?id=49734)

* The push_warning_printf() function was being called with an
invalid error level MYSQL_ERROR::WARN_LEVEL_ERROR, causing an
assertion failure. To fix the problem,
MYSQL_ERROR::WARN_LEVEL_ERROR has been replaced by
MYSQL_ERROR::WARN_LEVEL_WARN.
(Bug#49638: http://bugs.mysql.com/bug.php?id=49638)

* Some prepared statements could raise an assertion when
re-executed.
(Bug#49570: http://bugs.mysql.com/bug.php?id=49570)

* A Valgrind error in make_cond_for_table_from_pred() was
corrected. Thanks to Sergey Petrunya for the patch to fix this
bug. (Bug#49506: http://bugs.mysql.com/bug.php?id=49506)

* When compiling on Windows, an error in the CMake definitions
for InnoDB would cause the engine to be built incorrectly.
(Bug#49502: http://bugs.mysql.com/bug.php?id=49502)

* Valgrind warnings for CHECKSUM TABLE were corrected.
(Bug#49465: http://bugs.mysql.com/bug.php?id=49465)

* Specifying an index algorithm (such as BTREE) for SPATIAL or
FULLTEXT indexes caused a server crash. These index types do
not support algorithm specification, and it is now disallowed
to do so. (Bug#49250: http://bugs.mysql.com/bug.php?id=49250)

* The optimizer sometimes incorrectly handled conditions of the
form WHERE col_name='const1' AND col_name='const2'.
(Bug#49199: http://bugs.mysql.com/bug.php?id=49199)

* Execution of DECODE() and ENCODE() could be inefficient
because multiple executions within a single statement
reinitialized the random generator multiple times even with
constant parameters.
(Bug#49141: http://bugs.mysql.com/bug.php?id=49141)

* MySQL 5.1 does not support 2-byte collation numbers, but did
not check the number and crashed for out-of-range values.
(Bug#49134: http://bugs.mysql.com/bug.php?id=49134)

* With binary logging enabled, REVOKE ... ON
{PROCEDURE|FUNCTION} FROM ... could cause a crash.
(Bug#49119: http://bugs.mysql.com/bug.php?id=49119)

* The LIKE operator did not work correctly when using an index
for a ucs2 column.
(Bug#49028: http://bugs.mysql.com/bug.php?id=49028)

* check_key_in_view() was missing a DBUG_RETURN in one code
branch, causing a crash in debug builds.
(Bug#48995: http://bugs.mysql.com/bug.php?id=48995)

* Several strmake() calls had an incorrect length argument (too
large by one).
(Bug#48983: http://bugs.mysql.com/bug.php?id=48983)

* On Fedora 12, strmov() did not guarantee correct operation for
overlapping source and destination buffer. Calls were fixed to
use an overlap-safe version instead.
(Bug#48866: http://bugs.mysql.com/bug.php?id=48866)

* Incomplete reset of internal TABLE structures could cause a
crash with eq_ref table access in subqueries.
(Bug#48709: http://bugs.mysql.com/bug.php?id=48709)

* Re-execution of a prepared statement could cause a server
crash. (Bug#48508: http://bugs.mysql.com/bug.php?id=48508)

* The error message for ER_UPDATE_INFO was subject to buffer
overflow or truncation.
(Bug#48500: http://bugs.mysql.com/bug.php?id=48500)

* SHOW BINLOG EVENTS could fail with a error: Wrong offset or
I/O error. (Bug#48357: http://bugs.mysql.com/bug.php?id=48357)

* Valgrind warnings related to binary logging of LOAD DATA
INFILE statements were corrected.
(Bug#48340: http://bugs.mysql.com/bug.php?id=48340)

* An aliasing violation in the C API could lead to a crash.
(Bug#48284: http://bugs.mysql.com/bug.php?id=48284)

* The InnoDB Monitor could fail to print diagnostic information
after a long lock wait.
(Bug#47814: http://bugs.mysql.com/bug.php?id=47814)

* Queries containing GROUP BY ... WITH ROLLUP that did not use
indexes could return incorrect results.
(Bug#47650: http://bugs.mysql.com/bug.php?id=47650)

* If an invocation of a stored procedure failed in the
table-open stage, subsequent invocations that did not fail in
that stage could cause a crash.
(Bug#47649: http://bugs.mysql.com/bug.php?id=47649)

* On Solaris, no stack trace was printed to the error log after
a crash. (Bug#47391: http://bugs.mysql.com/bug.php?id=47391)

* The first execution of STOP SLAVE UNTIL stopped too early.
(Bug#47210: http://bugs.mysql.com/bug.php?id=47210)

* When the mysql client was invoked with the --vertical option,
it ignored the --skip-column-names option.
(Bug#47147: http://bugs.mysql.com/bug.php?id=47147)

* It was possible for init_available_charsets() not to
initialize correctly.
(Bug#45058: http://bugs.mysql.com/bug.php?id=45058)

* Comparison with NULL values sometimes did not produce a
correct result.
(Bug#42760: http://bugs.mysql.com/bug.php?id=42760)

* Crash recovery did not work for InnoDB temporary tables.
(Bug#41609: http://bugs.mysql.com/bug.php?id=41609)

* The mysql_upgrade command would create three additional fields
to the mysql.proc table (character_set_client,
collation_connection, and db_collation), but did not populate
the fields with correct values. This would lead to error
messages reported during stored procedure execution.
(Bug#41569: http://bugs.mysql.com/bug.php?id=41569)

* When compressed MyISAM files were opened, they were always
memory mapped, sometimes causing memory-swapping problems. To
deal with this, a new system variable, myisam_mmap_size, was
added to limit the amount of memory used for memory mapping of
MyISAM files.
(Bug#37408: http://bugs.mysql.com/bug.php?id=37408)

* A race condition on the privilege hash tables allowed one
thread to try to delete elements that had already been deleted
by another thread. A consequence was that SET PASSWORD or
FLUSH PRIVILEGES could cause a crash.
(Bug#35589: http://bugs.mysql.com/bug.php?id=35589,
Bug#35591: http://bugs.mysql.com/bug.php?id=35591)

* ALTER TABLE with both DROP COLUMN and ADD COLUMN clauses could
crash or lock up the server.
(Bug#31145: http://bugs.mysql.com/bug.php?id=31145)

MySQLや関連ソリューションに関するお問い合わせ、お見積などがございましたら、ご連絡ください。

お問い合わせ各MySQL保守サービス見積依頼スマートスタイルOSSストア

ページトップへ