2012年3月27日

[installer 3160] mysql-5.0.96, 5.1.62, 5.5.22

mysql-5.0.96, 5.1.62, 5.5.22 出ています。

☆ mysql-5.0.96
http://www.mysql.com/
http://dev.mysql.com/downloads/mysql/5.0.html

D.1.1 Changes in MySQL 5.0.96 (21 March 2012)
------------------------------------------------


End of Product Lifecycle

Active development for MySQL Database Server version 5.0 has ended.
Oracle offers various support offerings which may be of interest. For
details and more information, see the MySQL section of the Lifetime
Support Policy for Oracle Technology Products
http://www.oracle.com/us/support/lifetime-support/index.html). Please
consider upgrading to a recent version.

*Functionality Added or Changed*

* yaSSL was upgraded from version 1.7.2 to 2.2.0.


☆ mysql-5.1.62
http://www.mysql.com/
http://dev.mysql.com/downloads/mysql/5.1.html

D.1.1 Changes in MySQL 5.1.62 (21 March 2012)
------------------------------------------------

*Functionality Added or Changed*

* yaSSL was upgraded from version 1.7.2 to 2.2.0.

*Bugs Fixed*

* *Security Fix*: Bug #13510739 and Bug #63775 were fixed.

* *Incompatible Change*: An earlier change (in MySQL 5.1.59 and
5.5.16) was found to modify date-handling behavior in General
Availability-status series (MySQL 5.1 and 5.5). This change has
been reverted.

The change was that several functions became more strict when
passed a `DATE()' function value as their argument, thus they
rejected incomplete dates with a day part of zero. These functions
were affected: `CONVERT_TZ()', `DATE_ADD()', `DATE_SUB()',
`DAYOFYEAR()', `LAST_DAY()', `TIMESTAMPDIFF()', `TO_DAYS()',
`TO_SECONDS()'
http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_to-seconds),
`WEEK()', `WEEKDAY()', `WEEKOFYEAR()', `YEARWEEK()'. The previous
behavior has been restored. (Bug #13458237)

* *Important Change*: *InnoDB Storage Engine*: When a row grew in
size due to an `UPDATE' operation, other (non-updated) columns
could be moved to off-page storage so that information about the
row still fit within the constraints of the `InnoDB' page size.
The pointer to the new allocated off-page data was not set up
until the pages were allocated and written, potentially leading to
lost data if the system crashed while the column was being moved
out of the page. The problem was more common with tables using
`ROW_FORMAT=DYNAMIC' or `ROW_FORMAT=COMPRESSED' along with the
Barracuda file format, particularly with the
`innodb_file_per_table' setting enabled, because page allocation
operations are more common as the `.ibd' tablespace files are
extended. Still, the problem could occur with any combination of
InnoDB version, file format, and row format.

A related issue was that during such an `UPDATE' operation, or an
`INSERT' operation that reused a delete-marked record, other
transactions could see invalid data for the affected column,
regardless of isolation level.

The fix corrects the order of operations for moving the column
data off the original page and replacing it with a pointer. Now if
a crash occurs at the precise moment when the column data is being
transferred, the transfer will be re-run during crash recovery.

In MySQL 5.1, this fix applies to the InnoDB Plugin, but not the
built-in InnoDB storage engine. (Bug #13721257, Bug #12612184,
Bug #12704861)

* *InnoDB Storage Engine*: An erroneous assertion could occur, in
debug builds only, when creating an index on a column containing
zero-length values (that is, `'''). (Bug #13654923)

* *InnoDB Storage Engine*: A DDL operation such as `ALTER TABLE ...
ADD COLUMN' could stall, eventually timing out with an `Error
1005: Can't create table' message referring to
`fil_rename_tablespace'. (Bug #13636122, Bug #62100, Bug #63553)

* *InnoDB Storage Engine*: References to C preprocessor symbols and
macros `HAVE_purify', `UNIV_INIT_MEM_TO_ZERO', and
`UNIV_SET_MEM_TO_ZERO' were removed from the `InnoDB' source code.
They were only used in debug builds instrumented for Valgrind.
They are replaced by calls to the `UNIV_MEM_INVALID()' macro.
(Bug #13418934)

* *InnoDB Storage Engine*: A DDL operation for an `InnoDB' table
could cause a busy MySQL server to halt with an assertion error:

InnoDB: Failing assertion: trx->error_state == DB_SUCCESS

The error occurred if the DDL operation was run while all 1023
undo slots were in use by concurrent transactions. This error was
less likely to occur in MySQL 5.5 and 5.6, because raising the
number of `InnoDB' undo slots increased the number of simultaneous
transactions (corresponding to the number of undo slots) from 1K
to 128K. (Bug #12739098, Bug #62401)

* *InnoDB Storage Engine*: With 1024 concurrent `InnoDB' transactions
running concurrently and the `innodb_file_per_table' setting
enabled, a *Note `CREATE TABLE': create-table. operation for an
`InnoDB' table could fail. The `.ibd' file from the failed `CREATE
TABLE' was left behind, preventing the table from being created
later, after the load had dropped.

The fix adds error handling to delete the erroneous `.ibd' file.
This error was less likely to occur in MySQL 5.5 and 5.6, because
raising the number of `InnoDB' undo slots increased the number of
simultaneous transactions needed to trigger the bug, from 1K to
128K. (Bug #12400341)

* *InnoDB Storage Engine*: When copying a partitioned `InnoDB' table
from a Linux system to a Windows system, you could encounter this
error:

101115 14:19:53 [ERROR] Table .\test\d has no primary key in InnoDB data
dictionary, but has one in MySQL!

Normally, the solution to copy `InnoDB' tables from Linux to
Windows is to create the tables on Linux with the
`lower_case_table_names' option enabled. Partitioned tables, with
`#P#' appended to the filename, were not covered by that solution.
(Bug #11765438, Bug #58406)

* *InnoDB Storage Engine*: Server startup could produce an error for
temporary tables using the `InnoDB' storage engine, if the path in
the `$TMPDIR' variable ended with a `/' character. The error log
would look like:

120202 19:21:26 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
120202 19:21:26 InnoDB: Error: trying to open a table, but could not
InnoDB: open the tablespace file './t/#sql7750_1_0.ibd'!
InnoDB: Have you moved InnoDB .ibd files around without using the
InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE?
InnoDB: It is also possible that this is a temporary table #sql...,
InnoDB: and MySQL removed the .ibd file for this.

The workaround for the problem was to create a similar temporary
table again, copy its `.frm' file to `tmpdir' under the name
mentioned in the error message (for example, `#sql123.frm') and
restart `mysqld' with `tmpdir' set to its normal value without a
trailing slash, for example `/var/tmp'. On startup, MySQL would
see the `.frm' file and issue `DROP TABLE' for the orphaned
temporary table. (Bug #11754376, Bug #45976)

* A query that used an index on a *Note `CHAR': char. column
referenced in a `BETWEEN' clause could return invalid results.
(Bug #13463488, Bug #63437)

* When the optimizer performed conversion of *Note `DECIMAL':
numeric-types. values while evaluating range conditions, it could
produce incorrect results. (Bug #13453382)

* When used with the `--xml' option, *Note `mysqldump': mysqldump.
`--routines' failed to dump any stored routines, triggers, or
events. (Bug #11760384, Bug #52792)

* It was possible on replication slaves where *Note `FEDERATED':
federated-storage-engine. tables were in use to get timeouts on
long-running operations, such as Error 1160 `Got an error writing
communication packets'. The `FEDERATED' tables did not need to be
replicated for the issue to occur. (Bug #11758931, Bug #51196)
References: See also Bug #12896628, Bug #61790.

* If an attempt to initiate a statement failed, the issue could not
be reported to the client because it was not prepared to receive
any error messages prior to the execution of any statement. Since
the user could not execute any queries, they were simply
disconnected without providing a clear error.

After the fix for this issue, the client is prepared for an error
as soon as it attempts to initiate a statement, so that the error
can be reported prior to disconnecting the user. (Bug #11755281,
Bug #47032)

* Using *Note `myisamchk': myisamchk. with the sort recover method
to repair a table having fixed-width row format could cause the
row pointer size to be reduced, effectively resulting in a smaller
maximum data file size. (Bug #48848, Bug #11756869)

* Due to improper locking, concurrent inserts into an `ARCHIVE'
table at the same time as repair and check operations on the
table resulted in table corruption. (Bug #37280, Bug #11748748)


☆ mysql-5.5.22
http://www.mysql.com/
http://dev.mysql.com/downloads/mysql/5.5.html

D.1.1 Changes in MySQL 5.5.22 (21 March 2012)
------------------------------------------------

*Functionality Added or Changed*

* *InnoDB Storage Engine*: `--ignore-builtin-innodb' is now ignored
if used. (Bug #13586262)

* yaSSL was upgraded from version 1.7.2 to 2.2.0.

*Bugs Fixed*

* *Important Change*: *InnoDB Storage Engine*: When a row grew in
size due to an `UPDATE' operation, other (non-updated) columns
could be moved to off-page storage so that information about the
row still fit within the constraints of the `InnoDB' page size.
The pointer to the new allocated off-page data was not set up
until the pages were allocated and written, potentially leading to
lost data if the system crashed while the column was being moved
out of the page. The problem was more common with tables using
`ROW_FORMAT=DYNAMIC' or `ROW_FORMAT=COMPRESSED' along with the
Barracuda file format, particularly with the
`innodb_file_per_table' setting enabled, because page allocation
operations are more common as the `.ibd' tablespace files are
extended. Still, the problem could occur with any combination of
InnoDB version, file format, and row format.

A related issue was that during such an `UPDATE' operation, or an
`INSERT' operation that reused a delete-marked record, other
transactions could see invalid data for the affected column,
regardless of isolation level.

The fix corrects the order of operations for moving the column
data off the original page and replacing it with a pointer. Now if
a crash occurs at the precise moment when the column data is being
transferred, the transfer will be re-run during crash recovery.

In MySQL 5.1, this fix applies to the InnoDB Plugin, but not the
built-in InnoDB storage engine. (Bug #13721257, Bug #12612184,
Bug #12704861)

* *InnoDB Storage Engine*: An erroneous assertion could occur, in
debug builds only, when creating an index on a column containing
zero-length values (that is, `'''). (Bug #13654923)

* *InnoDB Storage Engine*: A DDL operation such as `ALTER TABLE ...
ADD COLUMN' could stall, eventually timing out with an `Error
1005: Can't create table' message referring to
`fil_rename_tablespace'. (Bug #13636122, Bug #62100, Bug #63553)

* *InnoDB Storage Engine*: A DDL operation for an `InnoDB' table
could cause a busy MySQL server to halt with an assertion error:

InnoDB: Failing assertion: trx->error_state == DB_SUCCESS

The error occurred if the DDL operation was run while all 1023
undo slots were in use by concurrent transactions. This error was
less likely to occur in MySQL 5.5 and 5.6, because raising the
number of `InnoDB' undo slots increased the number of simultaneous
transactions (corresponding to the number of undo slots) from 1K
to 128K. (Bug #12739098, Bug #62401)

* *InnoDB Storage Engine*: Server startup could produce an error for
temporary tables using the `InnoDB' storage engine, if the path in
the `$TMPDIR' variable ended with a `/' character. The error log
would look like:

120202 19:21:26 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
120202 19:21:26 InnoDB: Error: trying to open a table, but could not
InnoDB: open the tablespace file './t/#sql7750_1_0.ibd'!
InnoDB: Have you moved InnoDB .ibd files around without using the
InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE?
InnoDB: It is also possible that this is a temporary table #sql...,
InnoDB: and MySQL removed the .ibd file for this.

The workaround for the problem was to create a similar temporary
table again, copy its `.frm' file to `tmpdir' under the name
mentioned in the error message (for example, `#sql123.frm') and
restart `mysqld' with `tmpdir' set to its normal value without a
trailing slash, for example `/var/tmp'. On startup, MySQL would
see the `.frm' file and issue `DROP TABLE' for the orphaned
temporary table. (Bug #11754376, Bug #45976)

* *Replication*: Statements that wrote to tables with
`AUTO_INCREMENT' columns based on an unordered `SELECT' from
another table could lead to the master and the slave going out of
sync, as the order in which the rows are retrieved from the table
may differ between them. Such statements include any *Note
`INSERT ... SELECT': insert-select, *Note `REPLACE ... SELECT':
replace, or *Note `CREATE TABLE ... SELECT': create-table-select.
statement. Such statements are now marked as unsafe for
statement-based replication, which causes the execution of one to
throw a warning, and forces the statement to be logged using the
row-based format if the logging format is `MIXED'. (Bug
#11758263, Bug #50440)

* The contents of the `shared' and `shared-compat' RPM packages had
been changed in versions 5.5.6 and 5.6.1 to avoid the overlap
which they traditionally had (and still have in MySQL 5.0 and
5.1). However, the RPM meta information had not been changed in
accordance, and so RPM still assumed a conflict between shared
and `shared-compat' RPM packages. This has been fixed. (Bug
#60855, Bug #12368215)

References: See also Bug #56150.

* `myisam_sort_buffer_size' could not be set larger than 4GB on
64-bit systems. (Bug #45702, Bug #11754145)

* Due to improper locking, concurrent inserts into an `ARCHIVE'
table at the same time as repair and check operations on the
table resulted in table corruption. (Bug #37280, Bug #11748748)

----
こがよういちろう


投稿者 xml-rpc : 2012年3月27日 09:53
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/109133
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。