MySQL 5.1.42 リリース
投稿日時 2010-1-1 12:00:00 | トピック： MySQL 5.1
| MySQL 5.1.42 がリリースされました。これは MySQL 5.1 シリーズの最新バージョンです。
MySQL 5.0 シリーズは昨年末に EoL となっており（拡張サポートは2011年末まで）、今後はこのMySQL 5.1 シリーズの利用が勧められています。
このバージョンより、Mac OS X 10.6 、HP-UX 11.31、SLES 11 のバイナリが配布対象に加わりました。
ダウンロードはこちらから：
http://dev.mysql.com/downloads/mysql/5.1.html
--------
以下、チェンジログ(5.1.42)
■新規対象(5.1.42)：
* MySQL Server 5.1 is available on the following new
platforms starting with the 5.1.42 release:
+ Mac OS X 10.6 x86/x64
+ HP-UX 11.31 IA64
+ SLES 11 x86/x64
■重要な変更(5.1.42)：
Replication: The following functions
have been marked unsafe for statement-based replication:
+ GET_LOCK()
+ IS_FREE_LOCK()
+ IS_USED_LOCK()
+ MASTER_POS_WAIT()
+ RELEASE_LOCK()
+ SLEEP()
+ SYSDATE()
+ VERSION()
None of the functions just listed are guaranteed to
replicate correctly when using the statement-based
format, because they can produce different results on the
master and the slave. The use of any of these functions
while binlog_format is set to STATEMENT is logged with
the warning, Statement is not safe to log in statement
format. When binlog_format is set to MIXED, the binary
logging format is automatically switched to the row-based
format whenever one of these functions is used.
(Bug#47995: http://bugs.mysql.com/bug.php?id=47995)
■InnoDB Plugin 関係(5.1.42)：
* InnoDB Plugin has been upgraded to version 1.0.6. This
version is considered of Release Candidate (RC) quality.
The InnoDB Plugin Change History
(http://www.innodb.com/doc/innodb_plugin-1.0/innodb-changes.html)
may contain information in addition to those changes
reported here.
■バグ修正(5.1.42)：
* Performance: When the query cache is fragmented, the size of
the free block lists in the memory bins grows, which causes
query cache invalidation to become slow. There is now a 50ms
timeout for a SELECT statement waiting for the query cache
lock. If the timeout expires, the statement executes without
using the query cache.
(Bug#39253: http://bugs.mysql.com/bug.php?id=39253)
* Partitioning: In some cases, it was not possible to add a new
column to a table that had subpartitions.
(Bug#48276: http://bugs.mysql.com/bug.php?id=48276)
* Partitioning: SELECT COUNT(*) from a partitioned table failed
when using the ONLY_FULL_GROUP_BY SQL mode.
(Bug#46923: http://bugs.mysql.com/bug.php?id=46923)
This regression was introduced by
Bug#45807: http://bugs.mysql.com/bug.php?id=45807.
* Partitioning: SUBPARTITION BY KEY failed with DEFAULT
CHARSET=utf8.
(Bug#45904: http://bugs.mysql.com/bug.php?id=45904)
* Replication: When using row-based logging, TRUNCATE TABLE was
written to the binary log even if the affected table was
temporary, causing replication to fail.
(Bug#48350: http://bugs.mysql.com/bug.php?id=48350)
* Replication: Replicating TEXT or VARCHAR columns declared as
NULL on the master but NOT NULL on the slave caused the slave
to crash. (Bug#43789: http://bugs.mysql.com/bug.php?id=43789)
See also Bug#38850: http://bugs.mysql.com/bug.php?id=38850,
Bug#43783: http://bugs.mysql.com/bug.php?id=43783,
Bug#43785: http://bugs.mysql.com/bug.php?id=43785,
Bug#47741: http://bugs.mysql.com/bug.php?id=47741,
Bug#48091: http://bugs.mysql.com/bug.php?id=48091.
* InnoDB did not reset table AUTO_INCREMENT values to the last
used values after a server restart.
(Bug#49032: http://bugs.mysql.com/bug.php?id=49032)
* Privileges for stored routines were ignored for mixed-case
routine names.
(Bug#48872: http://bugs.mysql.com/bug.php?id=48872)
See also Bug#41049: http://bugs.mysql.com/bug.php?id=41049.
* Building MySQL on Fedora Core 12 64-bit would due to errors in
comp_err. (Bug#48864: http://bugs.mysql.com/bug.php?id=48864)
* Concurrent ALTER TABLE operations on an InnoDB table could
raise an assertion.
(Bug#48782: http://bugs.mysql.com/bug.php?id=48782)
* During query execution, ranges could be merged incorrectly for
OR operations and return an incorrect result.
(Bug#48665: http://bugs.mysql.com/bug.php?id=48665)
* The InnoDB Table Monitor reported the FLOAT and DOUBLE data
types incorrectly.
(Bug#48526: http://bugs.mysql.com/bug.php?id=48526)
* With row-based binary logging, the server crashed for
statements of the form CREATE TABLE IF NOT EXISTS
existing_view LIKE temporary_table. This occurred because the
server handled the existing view as a table when logging the
statement. (Bug#48506: http://bugs.mysql.com/bug.php?id=48506)
* DISTINCT was ignored for queries with GROUP BY WITH ROLLUP and
only const tables.
(Bug#48475: http://bugs.mysql.com/bug.php?id=48475)
* Loose index scan was inappropriately chosen for some WHERE
conditions.
(Bug#48472: http://bugs.mysql.com/bug.php?id=48472)
* A bad typecast could cause query execution to allocate large
amounts of memory.
(Bug#48458: http://bugs.mysql.com/bug.php?id=48458)
* On Windows, InnoDB could not be built as a statically linked
library. (Bug#48317: http://bugs.mysql.com/bug.php?id=48317)
* When running mysql_secure_installation, the command would fail
if the root password contained multiple spaces, \, # or quote
characters.
(Bug#48031: http://bugs.mysql.com/bug.php?id=48031)
* MATCH IN BOOLEAN MODE searches could return too many results
inside a subquery.
(Bug#47930: http://bugs.mysql.com/bug.php?id=47930)
* Connecting to a 4.1.x server from a 5.1.x or higher mysql
client resulted in a memory-free error when disconnecting.
(Bug#47655: http://bugs.mysql.com/bug.php?id=47655)
* Assignment of a system variable sharing the same base name as
a declared stored program variable in the same context could
lead to a crash.
(Bug#47627: http://bugs.mysql.com/bug.php?id=47627)
* The innodb_file_format_check system variable could not be set
at runtime to DEFAULT or to the value of a user-defined
variable. (Bug#47167: http://bugs.mysql.com/bug.php?id=47167)
* Valgrind errors for InnoDB Plugin were corrected.
(Bug#45992: http://bugs.mysql.com/bug.php?id=45992,
Bug#46656: http://bugs.mysql.com/bug.php?id=46656)
* On 64-bit systems, --skip-innodb did not skip InnoDB startup.
(Bug#46043: http://bugs.mysql.com/bug.php?id=46043)
* Truncation of DECIMAL values could lead to assertion failures;
for example, when deducing the type of a table column from a
literal DECIMAL value.
(Bug#45261: http://bugs.mysql.com/bug.php?id=45261)
See also Bug#48370: http://bugs.mysql.com/bug.php?id=48370.
* For YEAR(2) values, MIN(), MAX(), and comparisons could yield
incorrect results.
(Bug#43668: http://bugs.mysql.com/bug.php?id=43668)
* The server could crash when attempting to access a
non-conformant mysql.proc system table. For example, the
server could crash when invoking stored procedure-related
statements after an upgrade from MySQL 5.0 to 5.1 without
running mysql_upgrade.
(Bug#41726: http://bugs.mysql.com/bug.php?id=41726)
* When running mysql_secure_installation on Windows, the command
would fail to load a required module, Term::ReadKey, which was
required for correct operation.
(Bug#35106: http://bugs.mysql.com/bug.php?id=35106)
* If the --log-bin server option was set to a directory name
with a trailing component separator character, the basename of
the binary log files was empty so that the created files were
named .000001 and .index. The same thing occurred with the
--log-bin-index, --relay-log, and --relay-log-index options.
Now the server reports and error and exits.
(Bug#34739: http://bugs.mysql.com/bug.php?id=34739)
* On some Windows systems, InnoDB could report Operating system
error number 995 in a file operation due to transient driver
or hardware problems. InnoDB now retries the operation and
adds Retry attempt is made to the error message.
(Bug#3139: http://bugs.mysql.com/bug.php?id=3139)
* Replication: When using row-based format, replication
failed with the error Could not execute Write_rows event
on table ...; Field '...' doesn't have a default value
when an INSERT was made on the master without specifying
a value for a column having no default, even if strict
server SQL mode was not in use and the statement would
otherwise have succeeded on the master. Now the SQL mode
is checked, and the statement is replicated unless strict
mode is in effect. For more information, see Section
5.1.8, "Server SQL Modes."
(Bug#38173: http://bugs.mysql.com/bug.php?id=38173)
See also
Bug#38262: http://bugs.mysql.com/bug.php?id=38262,
Bug#43992: http://bugs.mysql.com/bug.php?id=43992.
* The result of comparison between nullable BIGINT and INT
columns was inconsistent.
(Bug#49517: http://bugs.mysql.com/bug.php?id=49517)
* Incorrect cache initialization prevented storage of
converted constant values and could produce incorrect
comparison results.
(Bug#49489: http://bugs.mysql.com/bug.php?id=49489)
* Comparisons involving YEAR values could produce incorrect
results.
(Bug#49480: http://bugs.mysql.com/bug.php?id=49480)
See also
Bug#43668: http://bugs.mysql.com/bug.php?id=43668.
* If a query involving a table was terminated with KILL, a
subsequent SHOW CREATE TABLE for that table caused a
server crash.
(Bug#48985: http://bugs.mysql.com/bug.php?id=48985)
* If the InnoDB tablespace was configured with too small a
value, the server could crash and corrupt the tablespace.
(Bug#48469: http://bugs.mysql.com/bug.php?id=48469)
* Parts of the range optimizer could be initialized
incorrectly, resulting in Valgrind errors.
(Bug#48459: http://bugs.mysql.com/bug.php?id=48459)
* On Windows, InnoDB could not be built as a statically
linked library.
(Bug#48317: http://bugs.mysql.com/bug.php?id=48317)
* mysql_secure_installation did not work on Solaris.
(Bug#48086: http://bugs.mysql.com/bug.php?id=48086)
* Using REPLACE to update a previously inserted negative
value in an AUTO_INCREMENT coumn in an InnoDB table
caused the table auto-increment value to be updated to
2147483647.
(Bug#47720: http://bugs.mysql.com/bug.php?id=47720)
* If a session held a global read lock acquired with FLUSH
TABLES WITH READ LOCK, a lock for one table acquired with
LOCK TABLES, and issued an INSERT DELAYED statement for
another table, deadlock could occur.
(Bug#47682: http://bugs.mysql.com/bug.php?id=47682)
* The mysql client status command displayed an incorrect
value for the server character set.
(Bug#47671: http://bugs.mysql.com/bug.php?id=47671)
* After a binary upgrade to MySQL 5.1 from a MySQL 5.0
installation that contains ARCHIVE tables, accessing
those tables caused the server to crash, even if you had
run mysql_upgrade or CHECK TABLE ... FOR UPGRADE.
To work around this problem, use mysqldump to dump all
ARCHIVE tables before upgrading, and reload them into
MySQL 5.1 after upgrading. The same problem occurs for
binary downgrades from MySQL 5.1 to 5.0.
(Bug#47012: http://bugs.mysql.com/bug.php?id=47012)
* The IGNORE clause on a DELETE statement masked an SQL
statement error that occurred during trigger processing.
(Bug#46425: http://bugs.mysql.com/bug.php?id=46425)
* The return value was not checked for some
my_hash_insert() calls.
(Bug#45613: http://bugs.mysql.com/bug.php?id=45613)
* Use of InnoDB monitoring (SHOW ENGINE INNODB STATUS or
one of the InnoDB Monitor tables) could cause a server
crash due to invalid access to a shared variable in a
concurrent environment. This is a further fix for a
regression introduced in MySQL 5.1.38 to the original fix
in MySQL 5.1.31.
(Bug#38883: http://bugs.mysql.com/bug.php?id=38883)
* If a comparison involved a constant value that required
type conversion, the converted value might not be cached,
resulting in repeated conversion and poorer performance.
(Bug#34384: http://bugs.mysql.com/bug.php?id=34384)
* Using the SHOW ENGINE INNODB STATUS statement when using
partitions in InnoDB tables caused Invalid (old?) table
or database name errors to be logged.
(Bug#32430: http://bugs.mysql.com/bug.php?id=32430)
* The Mac OS X 10.6 MySQL preference panel now contains
x86 64-bit binaries.
(Bug#46935: http://bugs.mysql.com/bug.php?id=46935)
|
|