MySQL Server 5.1.55 has been released (no replies)

Dear MySQL users,

MySQL Server 5.1.55, a new version of the popular Open Source
Database Management System, has been released. MySQL 5.1.55 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.55 on new servers or upgrading
to MySQL 5.1.55 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-55.html


Changes in MySQL 5.1.55 (7 February, 2011)

   Functionality added or changed:

     * The time zone tables available at
http://dev.mysql.com/downloads/timezones.html have been
       updated. These tables can be used on systems such as Windows
       or HP-UX that do not include zoneinfo files.
       (Bug#40230: http://bugs.mysql.com/bug.php?id=40230)

  Bugs fixed:

     * Incompatible Change: When auto_increment_increment is greater
       than one, values generated by a bulk insert that reaches the
       maximum column value could wrap around rather producing an
       overflow error.
       As a consequence of the fix, it is no longer possible for an
       auto-generated value to be equal to the maximum BIGINT
       UNSIGNED value. It is still possible to store that value
       manually, if the column can accept it.
       (Bug#39828: http://bugs.mysql.com/bug.php?id=39828)

     * Important Change: Partitioning: Date and time functions used
       as partitioning functions now have the types of their operands
       checked; use of a value of the wrong type is now disallowed in
       such cases. In addition, EXTRACT(WEEK FROM col), where col is
       a DATE or DATETIME column, is now disallowed altogether
       because its return value depends on the value of the
       default_week_format system variable.
       (Bug#54483: http://bugs.mysql.com/bug.php?id=54483)
       See also Bug#57071: http://bugs.mysql.com/bug.php?id=57071.

     * InnoDB Storage Engine: A compilation problem affected the
       InnoDB source code on NetBSD/sparc64.
       (Bug#59327: http://bugs.mysql.com/bug.php?id=59327)
       See also Bug#53916: http://bugs.mysql.com/bug.php?id=53916.

     * InnoDB Storage Engine: In InnoDB status output, the value for
       I/O sum[] could be incorrect, displayed as a very large
       number. (Bug#57600: http://bugs.mysql.com/bug.php?id=57600)

     * InnoDB Storage Engine: It was not possible to query the
       information_schema.innodb_trx table while other connections
       were running queries involving BLOB types.
       (Bug#55397: http://bugs.mysql.com/bug.php?id=55397)

     * InnoDB Storage Engine: The OPTIMIZE TABLE statement would
       reset the auto-increment counter for an InnoDB table. Now the
       auto-increment value is preserved across this operation.
       (Bug#18274: http://bugs.mysql.com/bug.php?id=18274)

     * Partitioning: Failed ALTER TABLE ... PARTITION statements
       could cause memory leaks.
       (Bug#56380: http://bugs.mysql.com/bug.php?id=56380)
       See also Bug#46949: http://bugs.mysql.com/bug.php?id=46949,
       Bug#56996: http://bugs.mysql.com/bug.php?id=56996.

     * Replication: When closing a session that used temporary
       tables, binary logging could sometimes fail with a spurious
       Failed to write the DROP statement for temporary tables to
       binary log.
       (Bug#57288: http://bugs.mysql.com/bug.php?id=57288)

     * Replication: By default, a value is generated for an
       AUTO_INCREMENT column by inserting either NULL or 0 into the
       column. Setting the NO_AUTO_VALUE_ON_ZERO server SQL mode
       suppresses this behavior for 0, so that it occurs only when
       NULL is inserted into the column.
       This behavior is also followed on a replication slave (by the
       slave SQL thread) when applying events that have been logged
       on the master using the statement-based format. However, when
       applying events that had been logged using the row-based
       format, NO_AUTO_VALUE_ON_ZERO was ignored, which could lead to
       an assertion.
       To fix this issue, the value of an AUTO_INCREMENT column is no
       longer generated when applying an event that was logged using
       the row-based row format, as this value is already contained
       in the changes applied on the slave.
       (Bug#56662: http://bugs.mysql.com/bug.php?id=56662)

     * Replication: The BINLOG statement modified the values of
       session variables, which could lead to problems with
       operations such a point-in-time recovery. One such case
       occurred when replaying a row-based binary log which relied on
       setting foreign_key_checks = OFF on the session level in order
       to create and populate a set of InnoDB tables having foreign
       key constraints.
       (Bug#54903: http://bugs.mysql.com/bug.php?id=54903)

     * Replication: mysqlbinlog printed USE statements to its output
       only when the default database changed between events. To
       illustrate how this could cause problems, suppose that a user
       issued the following sequence of statements:
CREATE DATABASE mydb;
USE mydb;
CREATE TABLE mytable (column_definitions);
DROP DATABASE mydb;
CREATE DATABASE mydb;
USE mydb;
CREATE TABLE mytable (column_definitions);
       When played back using mysqlbinlog, the second CREATE TABLE
       statement failed with Error: No Database Selected because the
       second USE statement was not played back, due to the fact that
       a database other than mydb was never selected.
       This fix insures that mysqlbinlog outputs a USE statement
       whenever it reads one from the binary log.
       (Bug#50914: http://bugs.mysql.com/bug.php?id=50914)

     * Replication: Previously, when a statement failed with a
       different error on the slave than on the master, the slave SQL
       thread displayed a message containing:

          + The error message for the master error code

          + The master error code

          + The error message for the slaves error code

          + The slave error code
       However, the slave has no information with which to fill in
       any print format specifiers for the master message, so it
       actually displayed the message format string. To make it
       clearer that the slave is not displaying the actual message as
       it appears on the master, the slave now indicates that the
       master part of the output is the message format, not the
       actual message. For example, previously the slave displayed
       information like this:
       Error: "Query caused different errors on master and slave.
       Error on master: 'Duplicate entry '%-.192s' for key %d'
       (1062), Error on slave: 'no error' (0). Default database:
       'test'. Query: 'insert into t1 values(1),(2)'" (expected
       different error codes on master and slave)
       Now the slave displays this:
       Error: "Query caused different errors on master and slave.
       Error on master: message format='Duplicate entry '%-.192s' for
       key %d' error code=1062 ; Error on slave: actual message='no
       error', error code=0. Default database: 'test'. Query: 'insert
       into t1 values(1),(2)'" (expected different error codes on
       master and slave)
       (Bug#46697: http://bugs.mysql.com/bug.php?id=46697)

     * Replication: When an error occurred in the generation of the
       name for a new binary log file, the error was logged but not
       shown to the user.
       (Bug#46166: http://bugs.mysql.com/bug.php?id=46166)
       See also Bug#37148: http://bugs.mysql.com/bug.php?id=37148,
       Bug#40611: http://bugs.mysql.com/bug.php?id=40611,
       Bug#43929: http://bugs.mysql.com/bug.php?id=43929,
       Bug#51019: http://bugs.mysql.com/bug.php?id=51019.

     * MIN(year_col) could return an incorrect result in some cases.
       (Bug#59211: http://bugs.mysql.com/bug.php?id=59211)

     * If max_allowed_packet was set larger than 16MB, the server
       failed to reject too-large packets with "Packet too large"
       errors. (Bug#58887: http://bugs.mysql.com/bug.php?id=58887)

     * Issuing EXPLAIN EXTENDED for a query that would use condition
       pushdown could cause mysqld to crash.
       (Bug#58553: http://bugs.mysql.com/bug.php?id=58553)

     * EXPLAIN could crash for queries that used GROUP_CONCAT().
       (Bug#58396: http://bugs.mysql.com/bug.php?id=58396)

     * Configuration with maintainer mode enabled resulted in errors
       when compiling with icc.
       (Bug#57991: http://bugs.mysql.com/bug.php?id=57991,
       Bug#58871: http://bugs.mysql.com/bug.php?id=58871)

     * Unnecessary subquery evaluation in contexts such as statement
       preparation or view creation could cause a server crash.
       (Bug#57703: http://bugs.mysql.com/bug.php?id=57703)

     * View creation could produce Valgrind warnings.
       (Bug#57352: http://bugs.mysql.com/bug.php?id=57352)

     * NULL geometry values could cause a crash in
       Item_func_spatial_collection::fix_length_and_dec.
       (Bug#57321: http://bugs.mysql.com/bug.php?id=57321)

     * The cp1251 character set did not properly support the Euro
       sign (0x88). For example, converting a string containing this
       character to utf8 resulted in '?' rather than the utf8 Euro
       sign. (Bug#56639: http://bugs.mysql.com/bug.php?id=56639)

     * Some unsigned system variables could be displayed with
       negative values.
       (Bug#55794: http://bugs.mysql.com/bug.php?id=55794)

     * CREATE DATABASE and DROP DATABASE caused mysql --one-database
       to lose track of the statement-filtering context.
       (Bug#54899: http://bugs.mysql.com/bug.php?id=54899)

     * An assertion could be raised during concurrent execution of
       DROP DATABASE and REPAIR TABLE if the drop deleted a table's
       .TMD file at the same time the repair tried to read details
       from the old file that was just removed.
       A problem could also occur when DROP TABLE tried to remove all
       files belonging to a table at the same time REPAIR TABLE had
       just deleted the table's .TMD file.
       (Bug#54486: http://bugs.mysql.com/bug.php?id=54486)

     * When mysqld printed crash dump information, it incorrectly
       indicated that some valid pointers were invalid.
       (Bug#51817: http://bugs.mysql.com/bug.php?id=51817)

     * On FreeBSD, if mysqld was killed with a SIGHUP signal, it
       could corrupt InnoDB .ibd files.
       (Bug#51023: http://bugs.mysql.com/bug.php?id=51023)

     * An assertion could be raised if -1 was inserted into an
       AUTO_INCREMENT column by a statement writing more than one
       row. (Bug#50619: http://bugs.mysql.com/bug.php?id=50619)

     * If a client supplied a user name longer than the maximum 16
       characters allowed for names stored in the MySQL grant tables,
       all characters were being considered significant.
       Historically, only the first 16 characters were used to check
       for a match; this behavior was restored.
       (Bug#49752: http://bugs.mysql.com/bug.php?id=49752)

     * The my_seek() and my_tell() functions ignored the MY_WME flag
       when they returned an error, which could cause client programs
       to hang. (Bug#48451: http://bugs.mysql.com/bug.php?id=48451)

     * During assignment of values to system variables, legality
       checks on the value range occurred too late, preventing proper
       error checking.
       (Bug#43233: http://bugs.mysql.com/bug.php?id=43233)

     * On Solaris, time-related functions such as NOW() or SYSDATE()
       could return a constant value.
       (Bug#42054: http://bugs.mysql.com/bug.php?id=42054)

     * If the remote server for a FEDERATED table could not be
       accessed, queries for the INFORMATION_SCHEMA.TABLES table
       failed. (Bug#35333: http://bugs.mysql.com/bug.php?id=35333)

Thanks,
Karen Langford
Release Engineer, MySQL, Oracle.