MySQL Community Server 5.1.53 has been released

Dear MySQL users,

MySQL Community Server 5.1.53, a new version of the popular Open
Source Database Management System, has been released. MySQL 5.1.53 is
recommended for use on production systems.

For an overview of what's new in MySQL 5.1, please see

http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html

For information on installing MySQL 5.1.53 on new servers or upgrading
to MySQL 5.1.53 from previous MySQL releases, please see

http://dev.mysql.com/doc/refman/5.1/en/installing.html

MySQL Server is available in source and binary form for a number of
platforms from our download pages at

http://dev.mysql.com/downloads/

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.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc.:

http://forge.mysql.com/wiki/Contributing

For information on open issues in MySQL 5.1, please see the errata
list at

http://dev.mysql.com/doc/refman/5.1/en/open-bugs.html

The following section lists the changes in the MySQL source code since
the previous released version of MySQL 5.1. It may also be viewed
online at

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-53.html

Enjoy!

============================================================ ===========

D.1.2. Changes in MySQL 5.1.53 (03 November 2010)

Bugs fixed:

* Replication: SET PASSWORD caused row-based replication to fail
between a MySQL 5.1 master and a MySQL 5.5 slave.
This fix makes it possible to replicate SET PASSWORD
correctly, using row-based replication between a master
running MySQL 5.1.53 or a later MySQL 5.1 release to a slave
running MySQL 5.5.7 or a later MySQL 5.5 release.
(Bug#57098: http://bugs.mysql.com/bug.php?id=57098)
See also Bug#55452: http://bugs.mysql.com/bug.php?id=55452,
Bug#57357: http://bugs.mysql.com/bug.php?id=57357.

* Replication: An ALTER TABLE statement against a MyISAM table
that altered a column without setting its size caused the
binary log to become corrupted, leading to replication
failure. (Bug#56226: http://bugs.mysql.com/bug.php?id=56226)

* Replication: When STOP SLAVE is issued, the slave SQL thread
rolls back the current transaction and stops immediately if
the transaction updates only tables which use transactional
storage engines are updated. Previously, this occurred even
when the transaction contained CREATE TEMPORARY TABLE
statements, DROP TEMPORARY TABLE statements, or both, although
these statements cannot be rolled back. Because temporary
tables persist for the lifetime of a user session (in the
case, the replication user), they remain until the slave is
stopped or reset. When the transaction is restarted following
a subsequent START SLAVE statement, the SQL thread aborts with
an error that a temporary table to be created (or dropped)
already exists (or does not exist, in the latter case).
Following this fix, if an ongoing transaction contains CREATE
TEMPORARY TABLE statements, DROP TEMPORARY TABLE statements,
or both, the SQL thread now waits until the transaction ends,
then stops.
(Bug#56118: http://bugs.mysql.com/bug.php?id=56118)

* Replication: If there exist both a temporary table and a
non-temporary table having the same, updates normally apply
only to the temporary table, with the exception of a CREATE
TABLE ... SELECT statement that creates a non-temporary table
having the same name as an existing temporary table. When such
a statement was replicated using the MIXED logging format, and
the statement was unsafe for row-based logging, updates were
misapplied to the temporary table.
(Bug#55478: http://bugs.mysql.com/bug.php?id=55478)
See also Bug#47899: http://bugs.mysql.com/bug.php?id=47899,
Bug#55709: http://bugs.mysql.com/bug.php?id=55709.

* Replication: When a slave tried to execute a transaction
larger than the slave's value for max_binlog_cache_size, it
crashed. This was caused by an assertion that the server
should roll back only the statement but not the entire
transaction when the error ER_TRANS_CACHE_FULL occurred.
However, the slave SQL thread always rolled back the entire
transaction whenever any error occurred, regardless of the
type of error.
(Bug#55375: http://bugs.mysql.com/bug.php?id=55375)

* Replication: When making changes to relay log settings using
CHANGE MASTER TO, the I/O cache was not cleared. This could
result in replication failure when the slave attempted to read
stale data from the cache and then stopped with an assertion.
(Bug#55263: http://bugs.mysql.com/bug.php?id=55263)

* Replication: Trying to read from a binary log containing a log
event of an invalid type caused the slave to crash.
(Bug#38718: http://bugs.mysql.com/bug.php?id=38718)

* Replication: When replicating the mysql.tables_priv table, the
Grantor column was not replicated, and was thus left empty on
the slave. (Bug#27606: http://bugs.mysql.com/bug.php?id=27606)

* SET GLOBAL debug could cause a crash on Solaris if the server
failed to open the trace file.
(Bug#57274: http://bugs.mysql.com/bug.php?id=57274)

* On file systems with case insensitive file names, and
lower_case_table_names=2, the server could crash due to a
table definition cache inconsistency.
(Bug#46941: http://bugs.mysql.com/bug.php?id=46941)

* Handling of host name lettercase in GRANT statements was
inconsistent.
(Bug#36742: http://bugs.mysql.com/bug.php?id=36742)

Thanks,
MySQL RE Team

Karen Langford MySQL Release Engineer
Database Group, Oracle.


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org