MySQL 5.5.2-m2 がリリースされました。このリリースは、MySQL 5.5 シリーズ(Betony)のマイルストンリリースです。
マイルストンリリースについては
http://forge.mysql.com/wiki/Development_Cycle
を参照ください。



　他のバージョン系列ではすでに対応されている「yaSSLに関するセキュリティ修正」がこのバージョンに含まれていますので、バージョン5.5.1-m2を使用中の方へは本バージョンへのアップデートが推奨されています。
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4484
http://bugs.mysql.com/50227


ダウンロードはこちらから。
http://dev.mysql.com/downloads/mysql/5.5.html


-----
以下チェンジログ(5.5.2-m2):



■InnoDBプラグイン関係：
* This release includes InnoDB Plugin 1.0.6. This version is
considered of Release Candidate (RC) quality.


■機能の追加と変更
* Replication: Introduced the
--binlog-direct-non-transactional-updates server option. This
option causes updates using the statement-based logging format
to tables using non-transactional engines to be written
directly to the binary log, rather than to the transaction
cache.
Before using this option, be certain that you have no
dependencies between transactional and non-transactional
tables. A statement that both selects from an InnoDB table and
inserts into a MyISAM table is an example of such a
dependency. For more information, see Section 16.1.3.4,
"Binary Log Options and Variables."
(Bug#46364: http://bugs.mysql.com/bug.php?id=46364)
See also Bug#28976: http://bugs.mysql.com/bug.php?id=28976,
Bug#40116: http://bugs.mysql.com/bug.php?id=40116.


■バグ修正
* Performance: The method for comparing INFORMATION_SCHEMA names
and database names was nonoptimal and an improvement was made:
When the database name length is already known, a length check
is made first and content comparison skipped if the lengths
are unequal.
(Bug#49501: http://bugs.mysql.com/bug.php?id=49501)

* Performance: The MD5() and SHA1() functions had excessive
overhead for short strings.
(Bug#49491: http://bugs.mysql.com/bug.php?id=49491)

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

* Incompatible Change: In plugin.h, the MYSQL_REPLICATION_PLUGIN
symbol was out of synchrony with its value in MySQL 6.0
because the lower-valued MYSQL_AUDIT_PLUGIN was not present.
To correct this, MYSQL_AUDIT_PLUGIN has been added in MySQL
5.5, changing the value of MYSQL_REPLICATION_PLUGIN from 5 to

6. Attempts to load the audit plugin produce an error occurs
because only the MYSQL_AUDIT_PLUGIN symbol was added, not the
audit plugin itself. This error will go away when the audit
plugin is added to MySQL 5.5. Replication plugins from earlier
5.5.x releases must be recompiled against the current release
before they will work with the current release.
(Bug#49894: http://bugs.mysql.com/bug.php?id=49894)

* 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: When an ALTER TABLE ... REORGANIZE PARTITION
statement on an InnoDB table failed due to
innodb_lock_wait_timeout expiring while waiting for a lock,
InnoDB did not clean up any temporary files or tables which it
had created. Attempting to reissue the ALTER TABLE statement
following the timeout could lead to storage engine errors, or
possibly a crash of the server.
(Bug#47343: http://bugs.mysql.com/bug.php?id=47343)

* Replication: FLUSH LOGS could in some circumstances crash the
server. This occurred because the I/O thread could
concurrently access the relay log I/O cache while another
thread was performing the FLUSH LOGS, which closes and reopens
the relay log and, while doing so, initializes (or
re-initializes) its I/O cache. This could cause problems if
some other thread (in this case, the I/O thread) is accessing
it at the same time.
Now the thread performing the FLUSH LOGS takes a lock on the
relay log before actually flushing it.
(Bug#50364: http://bugs.mysql.com/bug.php?id=50364)

* Replication: With semisynchronous replication, memory
allocated for handling transactions could be freed while still
in use, resulting in a server crash.
(Bug#50157: http://bugs.mysql.com/bug.php?id=50157)

* Replication: In some cases, inserting into a table with many
columns could cause the binary log to become corrupted.
(Bug#50018: http://bugs.mysql.com/bug.php?id=50018)
See also Bug#42749: http://bugs.mysql.com/bug.php?id=42749.

* Replication: When using row-based replication, setting a BIT
or CHAR column of a MyISAM table to NULL, then trying to
delete from the table, caused the slave to fail with the error
Can't find record in table.
(Bug#49481: http://bugs.mysql.com/bug.php?id=49481,
Bug#49482: http://bugs.mysql.com/bug.php?id=49482)

* Replication: A LOAD DATA INFILE statement that loaded data
into a table having a column name that had to 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 into the binary log without escaping the column
names. (Bug#49479: http://bugs.mysql.com/bug.php?id=49479)
See also Bug#47927: http://bugs.mysql.com/bug.php?id=47927.

* Replication: When logging in row-based mode, DDL statements
are actually logged as statements; however, statements that
affected temporary tables and followed DDL statements failed
to reset the binary log format to ROW, with the result that
these statements were logged using the statement-based format.
Now the state of binlog_format is restored after a DDL
statement has been written to the binary log.
(Bug#49132: http://bugs.mysql.com/bug.php?id=49132)

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

* Replication: When using row-based logging, the statement
CREATE TABLE t IF NOT EXIST ... SELECT was logged as CREATE
TEMPORARY TABLE t IF NOT EXIST ... SELECT when t already
existed as a temporary table. This was caused by the fact that
the temporary table was opened and the results of the SELECT
were inserted into it when a temporary table existed and had
the same name.
Now, when this statement is executed, t is created as a base
table, the results of the SELECT are inserted into it --- even
if there already exists a temporary table having the same name
--- and the statement is logged correctly.
(Bug#47418: http://bugs.mysql.com/bug.php?id=47418)
See also Bug#47442: http://bugs.mysql.com/bug.php?id=47442.

* Replication: Due to a change in the size of event
representations in the binary log, when replicating from a
MySQL 4.1 master to a slave running MySQL 5.0.60 or later, the
START SLAVE UNTIL statement did not function correctly,
stopping at the wrong position in the log. Now the slave
detects that the master is using the older version of the
binary log format, and corrects for the difference in event
size, so that the slave stops in the correct position.
(Bug#47142: http://bugs.mysql.com/bug.php?id=47142)

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

* The SSL certificates in the test suite were about to expire.
They have been updated with expiration dates in the year 2015.
(Bug#50642: http://bugs.mysql.com/bug.php?id=50642)

* SPATIAL indexes were allowed on columns with non-spatial data
types, resulting in a server crash for subsequent table
inserts. (Bug#50574: http://bugs.mysql.com/bug.php?id=50574)

* Index prefixes could be specified with a length greater than
the associated column, resulting in a server crash for
subsequent table inserts.
(Bug#50542: http://bugs.mysql.com/bug.php?id=50542)

* Use of loose index scan optimization for an aggregate function
with DISTINCT (for example, COUNT(DISTINCT)) could produce
incorrect results.
(Bug#50539: http://bugs.mysql.com/bug.php?id=50539)

* The printstack function does not exist on Solaris 8 or
earlier, which would lead to a compilation failure.
(Bug#50409: http://bugs.mysql.com/bug.php?id=50409)

* A user could see tables in INFORMATION_SCHEMA.TABLES without
appropriate privileges for them.
(Bug#50276: http://bugs.mysql.com/bug.php?id=50276)

* Debug output for join structures was garbled.
(Bug#50271: http://bugs.mysql.com/bug.php?id=50271)

* 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 filesort sorting method applied to a CHAR(0) column could
lead to a server crash.
(Bug#49897: http://bugs.mysql.com/bug.php?id=49897)

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

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

* sql_buffer_result had an effect on non-SELECT statements,
contrary to the documentation.
(Bug#49552: http://bugs.mysql.com/bug.php?id=49552)

* In some cases a subquery need not be evaluated because it
returns only aggregate values that can be calculated from
table metadata. This sometimes was not handled by the
enclosing subquery, resulting in a server crash.
(Bug#49512: http://bugs.mysql.com/bug.php?id=49512)

* Mixing full-text searches and row expressions caused a crash.
(Bug#49445: http://bugs.mysql.com/bug.php?id=49445)

* Creating or dropping a table with 1023 transactions active
caused an assertion failure.
(Bug#49238: http://bugs.mysql.com/bug.php?id=49238)

* mysql-test-run.pl now recognizes the MTR_TESTCASE_TIMEOUT,
MTR_SUITE_TIMEOUT, MTR_SHUTDOWN_TIMEOUT, and MTR_START_TIMEOUT
environment variables. If they are set, their values are used
to set the --testcase-timeout, --suite-timeout,
--shutdown-timeout, and --start-timeout options, respectively.
(Bug#49210: http://bugs.mysql.com/bug.php?id=49210)

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

* With one thread waiting for a lock on a table, if another
thread dropped the table and created a new table with the same
name and structure, the first thread would not notice that the
table had been re-created and would try to used cached
metadata that belonged to the old table but had been freed.
(Bug#48157: http://bugs.mysql.com/bug.php?id=48157)

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

* A crash occurred when a user variable that was assigned to a
subquery result was used as a result field in a SELECT
statement with aggregate functions.
(Bug#47371: http://bugs.mysql.com/bug.php?id=47371)

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

* If EXPLAIN encountered an error in the query, a memory leak
occurred. (Bug#45989: http://bugs.mysql.com/bug.php?id=45989)

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

* 1) In rare cases, if a thread was interrupted during a FLUSH
PRIVILEGES operation, a debug assertion occurred later due to
improper diagnostic area setup. 2) A KILL operation could
cause a console error message referring to a diagnostic area
state without first ensuring that the state existed.
(Bug#33982: http://bugs.mysql.com/bug.php?id=33982)

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

* The Table_locks_waited waited variable was not incremented in
the cases that a lock had to be waited for but the waiting
thread was killed or the request was aborted.
(Bug#30331: http://bugs.mysql.com/bug.php?id=30331)