MySQL 5.1.47 リリース！
投稿日時 2010-5-22 12:10:00 | トピック： MySQL 5.1
| MySQL 5.1.47 がリリースされました。このバージョンは、現行最新メジャーバージョンである MySQL 5.1 シリーズの最新バージョンです。
このリリースでは、InnoDB Plugin が 1.0.8 になりました。
また、セキュリティFIXも含まれています。詳しくはチェンジログをご覧ください。
ダウンロードはこちらから：
http://dev.mysql.com/downloads/mysql/5.1.html
----
以下、チェンジログ(5.1.47)：
■InnoDB Plugin について：
* InnoDB Plugin has been upgraded to version 1.0.8. This version
is considered of General Availability (GA) quality. InnoDB
Plugin Change History
(http://dev.mysql.com/doc/innodb-plugin/1.0/en/innodb-changes.
html), may contain information in addition to those changes
reported here.
In this release, the InnoDB Plugin is included in source and
binary distributions, except RHEL3, RHEL4, SuSE 9 (x86,
x86_64, ia64), and generic Linux RPM packages. It also does
not work for FreeBSD 6 and HP-UX or for Linux on generic ia64.
■機能の追加と変更：
* InnoDB stores redo log records in a hash table during
recovery. On 64-bit systems, this hash table was 1/8 of the
buffer pool size. To reduce memory usage, the dimension of the
hash table was reduced to 1/64 of the buffer pool size (or
1/128 on 32-bit systems).
(Bug#53122: http://bugs.mysql.com/bug.php?id=53122)
■バグ修正：
* Security Fix: The server failed to check the table name
argument of a COM_FIELD_LIST command packet for validity and
compliance to acceptable table name standards. This could be
exploited to bypass almost all forms of checks for privileges
and table-level grants by providing a specially crafted table
name argument to COM_FIELD_LIST.
In MySQL 5.0 and above, this allowed an authenticated user
with SELECT privileges on one table to obtain the field
definitions of any table in all other databases and
potentially of other MySQL instances accessible from the
server's file system.
Additionally, for MySQL version 5.1 and above, an
authenticated user with DELETE or SELECT privileges on one
table could delete or read content from any other table in all
databases on this server, and potentially of other MySQL
instances accessible from the server's file system.
(Bug#53371: http://bugs.mysql.com/bug.php?id=53371,
CVE-2010-1848
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1848))
* Security Fix: The server was susceptible to a buffer-overflow
attack due to a failure to perform bounds checking on the
table name argument of a COM_FIELD_LIST command packet. By
sending long data for the table name, a buffer is overflown,
which could be exploited by an authenticated user to inject
malicious code.
(Bug#53237: http://bugs.mysql.com/bug.php?id=53237,
CVE-2010-1850
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1850))
* Security Fix: The server could be tricked into reading packets
indefinitely if it received a packet larger than the maximum
size of one packet.
(Bug#50974: http://bugs.mysql.com/bug.php?id=50974,
CVE-2010-1849
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1849))
* Important Change: Replication: When invoked, CHANGE MASTER TO
and SET GLOBAL sql_slave_skip_counter now cause information to
be written to the error log about the slave's state prior to
execution of the statement. For CHANGE MASTER TO, this
information includes the previous values for MASTER_HOST,
MASTER_PORT, MASTER_LOG_FILE, and MASTER_LOG_POS. For SET
GLOBAL SQL_SLAVE_SKIP_COUNTER, this information includes the
previous values of sql_slave_skip_counter, the group relay log
name, and the group relay log position.
(Bug#43406: http://bugs.mysql.com/bug.php?id=43406,
Bug#43407: http://bugs.mysql.com/bug.php?id=43407)
* Replication: The failure of a REVOKE statement was logged with
the wrong error code, causing replication slaves to stop even
when the failure was expected on the master.
(Bug#51987: http://bugs.mysql.com/bug.php?id=51987)
* Certain path names passed to LOAD_FILE() could cause a server
crash. (Bug#53417: http://bugs.mysql.com/bug.php?id=53417)
* When reporting a foreign key constraint violation during
INSERT, InnoDB could display uninitialized data for the
DB_TRX_ID and DB_ROLL_PTR system columns.
(Bug#53202: http://bugs.mysql.com/bug.php?id=53202)
* InnoDB page splitting could enter an infinite loop for
compressed tables.
(Bug#52964: http://bugs.mysql.com/bug.php?id=52964)
* An overly strict assertion could fail during the purge of
delete-marked records in DYNAMIC or COMPRESSED InnoDB tables
that contain column prefix indexes.
(Bug#52746: http://bugs.mysql.com/bug.php?id=52746)
* InnoDB attempted to choose off-page storage without ensuring
that there was an "off-page storage" flag in the record
header. To correct this, in DYNAMIC and COMPRESSED formats,
InnoDB stores locally any non-BLOB columns having a maximum
length not exceeding 256 bytes. This is because there is no
room for the "external storage" flag when the maximum length
is 255 bytes or less. This restriction trivially holds in
REDUNDANT and COMPACT formats, because there InnoDB always
stores locally columns having a length up to local_len = 788
bytes. (Bug#52745: http://bugs.mysql.com/bug.php?id=52745)
* Semi-consistent read was implemented for InnoDB to address
Bug#3300: http://bugs.mysql.com/bug.php?id=3300.
Semi-consistent reads do not block when a nonmatching record
is already locked by some other transaction. If the record is
not locked, a lock is acquired, but is released if the record
does not match the WHERE condition. However, semi-consistent
read was attempted even for UPDATE statements having a WHERE
condition of the form pk_col1=constant1, ...,
pk_colN=constantN. Some code that was designed with the
assumption that semi-consistent read would be only attempted
on table scans, failed.
(Bug#52663: http://bugs.mysql.com/bug.php?id=52663)
* Setting @@GLOBAL.debug to an empty string failed to clear the
current debug settings.
(Bug#52629: http://bugs.mysql.com/bug.php?id=52629)
* A memory leak occurred due to missing deallocation of the
comparators array (a member of the Arg_comparator class).
(Bug#52124: http://bugs.mysql.com/bug.php?id=52124)
* For debug builds, creating a view containing a subquery that
might require collation adjustment caused an assertion to be
raised. For example, this could occur if some items had
different collations but the result collation could be
adjusted to the one of them.
(Bug#52120: http://bugs.mysql.com/bug.php?id=52120)
* Connections waiting for an InnoDB row lock ignored KILL until
the row lock wait ended. Now, KILL during lock wait results in
"query interrupted" instead of "lock wait timeout exceeded".
(Bug#51920: http://bugs.mysql.com/bug.php?id=51920)
* Locking involving the LOCK_plugin,
LOCK_global_system_variables, and LOCK_status mutexes could
deadlock. (Bug#51591: http://bugs.mysql.com/bug.php?id=51591)
* InnoDB fast index creation could incorrectly use a table copy
in some cases.
(Bug#50946: http://bugs.mysql.com/bug.php?id=50946)
* A syntactically invalid trigger could cause the server to
crash when trying to list triggers.
(Bug#50755: http://bugs.mysql.com/bug.php?id=50755)
* InnoDB Plugin checks to see whether a row could possibly
exceed the maximum size if all columns are fully used. This
produced Row size too large errors for some tables that could
be created with the built-in InnoDB. Now the check is only
done when innodb_strict_mode is enabled or if the table is
dynamic or compressed.
(Bug#50495: http://bugs.mysql.com/bug.php?id=50495)
* In MySQL 5.1, READ COMMITTED was changed to use less locking
due to the availability of row based binary logging (see the
Note under READ COMMITTED at Section 12.3.6, "SET TRANSACTION
Syntax"). However, READ UNCOMMITTED did not have the same
change, so it was using more locks than the higher isolation
level, which is unexpected. This was changed so that READ
UNCOMMITTED now also uses the lesser amount of locking and has
the same restrictions for binary logging.
(Bug#48607: http://bugs.mysql.com/bug.php?id=48607)
* EXPLAIN could cause a server crash for some queries with
subqueries.
(Bug#48419: http://bugs.mysql.com/bug.php?id=48419)
* On Windows, the server failed to find a description for Event
ID 100. (Bug#48042: http://bugs.mysql.com/bug.php?id=48042)
* For updates to InnoDB tables, TIMESTAMP columns could be
updated even when no values actually changed.
(Bug#47453: http://bugs.mysql.com/bug.php?id=47453)
* If the server is started with --skip-grant-tables, plugin
loading and unloading should be disallowed, but the server
failed to reject INSTALL PLUGIN and UNINSTALL PLUGIN
statements.
(Bug#46261: http://bugs.mysql.com/bug.php?id=46261)
* Storage engine plugins on Windows could've been built with a
definition of time_t which was different from the server
expectations. The difference could cause affected plugins to
crash. In addition, the use of the time_t type in the storage
engine API layer has been enforced.
(Bug#39802: http://bugs.mysql.com/bug.php?id=39802,
Bug#40092: http://bugs.mysql.com/bug.php?id=40092)
* When using UNINSTALL PLUGIN to remove a loaded plugin, open
tables and connections caused mysqld to hang until the open
connections had been closed.
(Bug#39053: http://bugs.mysql.com/bug.php?id=39053)
* 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)
|
|