MySQL Community Server 5.1.62 has been released

[Karen Langford]

Dear MySQL users,

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

Enjoy!

=======================================================================
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-function
       s.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 not 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 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 d
ata
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 op
eration.
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 CHAR column referenced in a
       BETWEEN clause could return invalid results. (Bug #13463488,
       Bug #63437)

     * When the optimizer performed conversion of DECIMAL values
       while evaluating range conditions, it could produce incorrect
       results. (Bug #13453382)

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

     * It was possible on replication slaves where FEDERATED 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 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)

Thanks,
MySQL RE Team
Database Group, Oracle.