|| ||Joerg Bruehe <joerg-AT-mysql.com>|
|| ||announce-AT-lists.mysql.com, packagers-AT-lists.mysql.com,
MySQL General List <mysql-AT-lists.mysql.com>|
|| ||MySQL 5.1.22-rc has been released|
|| ||Sun, 30 Sep 2007 20:48:10 +0200|
|| ||Damien Seguy <damien.seguy-AT-nexen.net>|
Dear MySQL users,
we are proud to present to you the MySQL Server 5.1.22-rc release,
the first 5.1 "release candidate" version of the popular open source
Bear in mind that this is still a "candidate" release, and as with any
other pre-production release, caution should be taken when installing on
production level systems or systems with critical data. For production
level systems using 5.0, we would like to direct your attention to the
product description of MySQL Enterprise at:
The MySQL 5.1.22-rc release is now available in source and binary form
for a number of platforms from our download pages at
and mirror sites. Note that not all mirror sites may be up to date at
this point in time, so if you can't find this version on some mirror,
please try again later or choose another download site.
Please also note that some of our mirrors are currently experiencing
problems that may result in serving corrupted files. We are working with
the mirror maintainers to resolve this.
We welcome and appreciate your feedback, bug reports, bug fixes,
The following section lists the changes from version to version in the
MySQL source code since the latest released version of MySQL 5.1, the
MySQL 5.1.21-beta release. It can also be viewed online at
Functionality added or changed:
* There is a new innodb_autoinc_lock_mode system variable to
configure the locking behavior that InnoDB uses for generating
auto-increment values. The default behavior now is slightly
different from before, which involves a minor incompatibility
for multiple-row inserts that specify an explicit value for
the auto-increment column in some but not all rows.
This can be used to improve scalability and performance, see
Section 18.104.22.168, "How AUTO_INCREMENT Handling Works in InnoDB.":
* NDB Cluster: Backups of TIMESTAMP columns made with
ndb_restore on a MySQL Cluster using data nodes hosts of one
endian could not be used to restore the cluster's data to data
node hosts of the other endian.
* NDB Cluster (Replication): Multi-master replication setups did
not handle --log-slave-updates correctly.
* When sorting rows in an INNODB table using a primary key,
where the sort was on the the primary key column and the DESC
operator was applied, the rows would be incorrectly sorted if
you included a simple WHERE field = value clause in the query.
* Replication of InnoDB partitioned tables could lose updates
with row-based or mixed replication format.
* mysql_install_db could fail to find its message file.
* Non-range queries of the form SELECT ... FROM ... WHERE
keypart_1=const, ..., keypart_n=const ORDER BY ... FOR UPDATE
sometimes were unnecessarily blocked waiting for a lock if
another transaction was using SELECT ... FOR UPDATE on the
same table. (Bug#28570: http://bugs.mysql.com/28570)
* Under some circumstances, a UDF initialization function could
be passed incorrect argument lengths.
* CONNECTION_ID() always returned 0 for the embedded server
(libmysqld). (Bug#30389: http://bugs.mysql.com/30389)
* The mysql_list_fields() C API function incorrectly set
MYSQL_FIELD::decimals for some view columns.
* Read lock requests that were blocked by a pending write lock
request were not allowed to proceed if the statement
requesting the write lock was killed.
* Memory corruption occurred for some queries with a top-level
OR operation in the WHERE condition if they contained equality
predicates and other sargable predicates in disjunctive parts
of the condition. (Bug#30396: http://bugs.mysql.com/30396)
* The server created temporary tables for filesort operations in
the working directory, not in the directory specified by the
tmpdir system variable.
* Using KILL QUERY or KILL CONNECTION to kill a SELECT statement
caused a server crash if the query cache was enabled.
* Operations that used the time zone replicated the time zone
only for successful operations, but did not replicate the time
zone for errors that need to know it.
* mysqldump from the MySQL 5.1.21 distribution could not be used
to create a dump from a MySQL 5.1.20 or older server.
* When using a combination of HANDLER... READ and DELETE on a
table, MySQL continued to open new copies of the table every
time, leading to an exhaustion of file descriptors. This was
caused in MySQL 5.1.15 by a fix for
Bug#21587: http://bugs.mysql.com/21587; the current fix
consists of reverting the earlier fix.
* Tables using the InnoDB storage engine incremented
AUTO_INCREMENT values incorrectly with ON DUPLICATE KEY
UPDATE. (Bug#28781: http://bugs.mysql.com/28781)
Joerg Bruehe, Senior Production Engineer
MySQL AB, www.mysql.com
to post comments)