MySQL Forums
Forum List  »  Announcements

MySQL Community Server 5.1.49 has been released
Posted by: Karen Langford
Date: July 23, 2010 07:55AM

Dear MySQL users,

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

Enjoy!

=======================================================================
C.1.2. Changes in MySQL 5.1.49 (09 July 2010)

   InnoDB Notes:

     * InnoDB Plugin has been upgraded to version 1.0.10. This
       version is considered of General Availability (GA) quality.
       InnoDB Plugin Change History
       (http://dev.mysql.com/doc/innodb-plugin/1.0/en/innodb-changes.
       html), may contain information in addition to those changes
       reported here.
       In this release, the InnoDB Plugin is included in source and
       binary distributions, except RHEL3, RHEL4, SuSE 9 (x86,
       x86_64, ia64), and generic Linux RPM packages. It also does
       not work for FreeBSD 6 and HP-UX or for Linux on generic ia64.

   Bugs fixed:

     * Replication: When using unique keys on NULL columns in
       row-based replication, the slave sometimes chose the wrong row
       when performing an update. This happened because a table
       having a unique key on such a column could have multiple rows
       containing NULL for the column used by the unique key, and the
       slave merely picked the first row containing NULL in that
       column. (Bug#53893: http://bugs.mysql.com/bug.php?id=53893)

     * Replication: FLUSH LOGS could in some circumstances crash the
       server. This occurred because the I/O thread could
       concurrently access the relay log I/O cache while another
       thread was performing the FLUSH LOGS, which closes and reopens
       the relay log and, while doing so, initializes (or
       re-initializes) its I/O cache. This could cause problems if
       some other thread (in this case, the I/O thread) is accessing
       it at the same time.
       Now the thread performing the FLUSH LOGS takes a lock on the
       relay log before actually flushing it.
       (Bug#53657: http://bugs.mysql.com/bug.php?id=53657)
       See also Bug#50364: http://bugs.mysql.com/bug.php?id=50364.

     * Replication: Two related issues involving temporary tables and
       transactions were introduced by a fix made in MySQL 5.1.37:

         1. When a temporary table was created or dropped within a
            transaction, any failed statement that following the
            CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE statement
            triggered a rollback, which caused the slave diverge from
            the master.

         2. When a CREATE TEMPORARY TABLE ... SELECT * FROM ...
            statement was executed within a transaction in which only
            tables using transactional storage engines were used and
            the transaction was rolled back at the end, the
            changes---including the creation of the temporary
            table---were not written to the binary log.
       The current fix restores the correct behavior in both of these
       cases. (Bug#53560: http://bugs.mysql.com/bug.php?id=53560)
       This regression was introduced by
       Bug#43929: http://bugs.mysql.com/bug.php?id=43929.

     * Replication: When CURRENT_USER() or CURRENT_USER was used to
       supply the name and host of the affected user or of the
       definer in any of the statements DROP USER, RENAME USER,
       GRANT, REVOKE, and ALTER EVENT, the reference to
       CURRENT_USER() or CURRENT_USER was not expanded when written
       to the binary log. This resulted in CURRENT_USER() or
       CURRENT_USER being expanded to the user and host of the slave
       SQL thread on the slave, thus breaking replication. Now
       CURRENT_USER() and CURRENT_USER are expanded prior to being
       written to the binary log in such cases, so that the correct
       user and host are referenced on both the master and the slave.
       (Bug#48321: http://bugs.mysql.com/bug.php?id=48321)

     * An ALTER TABLE statement could convert an InnoDB compressed
       table (with row_format=compressed) back to an uncompressed
       table (with row_format=compact).
       (Bug#54679: http://bugs.mysql.com/bug.php?id=54679)

     * A signal-handler redefinition for SIGUSR1 was removed. The
       redefinition could cause the server to encounter a kernel
       deadlock on Solaris when there are many active threads. Other
       POSIX platforms might also be affected.
       (Bug#54667: http://bugs.mysql.com/bug.php?id=54667)

     * InnoDB could issue an incorrect message on startup, if tables
       were created under the setting innodb_file_per_table=ON and
       the server was restarted under the setting
       innodb_file_per_table=OFF. The message was of the form InnoDB:
       Warning: allocated tablespace n, old maximum was 0.
       (Bug#54658: http://bugs.mysql.com/bug.php?id=54658)

     * The make_binary_distribution target to make could fail on some
       platforms because the lines generated were too long for the
       shell. (Bug#54590: http://bugs.mysql.com/bug.php?id=54590)

     * The server failed to disregard sort order for some zero-length
       tuples, leading to an assertion failure.
       (Bug#54459: http://bugs.mysql.com/bug.php?id=54459)

     * The default value of myisam_max_extra_sort_file_size
       (http://dev.mysql.com/doc/refman/5.0/en/server-system-variable
       s.html#sysvar_myisam_max_extra_sort_file_size) could be higher
       than the maximum accepted value, leading to warnings upon the
       server start.
       (Bug#54457: http://bugs.mysql.com/bug.php?id=54457)

     * If a session tried to drop a database containing a table
       opened with HANDLER in another session, any DATABASE statement
       (CREATE, DROP, ALTER) executed by that session produced a
       deadlock. (Bug#54360: http://bugs.mysql.com/bug.php?id=54360)

     * Fast index creation could fail, leaving the new secondary
       index corrupted.
       (Bug#54330: http://bugs.mysql.com/bug.php?id=54330)

     * A client could supply data in chunks to a prepared statement
       parameter other than of type TEXT or BLOB using the
       mysql_stmt_send_long_data() C API function (or
       COM_STMT_SEND_LONG_DATA command). This led to a crash because
       other data types are not valid for long data.
       (Bug#54041: http://bugs.mysql.com/bug.php?id=54041)

     * Builds of the embedded mysqld would fail due to a missing
       element of the struct NET.
       (Bug#53908: http://bugs.mysql.com/bug.php?id=53908,
       Bug#53912: http://bugs.mysql.com/bug.php?id=53912)

     * The definition of the MY_INIT macro in my_sys.h included an
       extraneous semicolon, which could cause compilation failure.
       (Bug#53906: http://bugs.mysql.com/bug.php?id=53906)

     * A client with automatic reconnection enabled saw the error
       message Lost connection to MySQL server during query if the
       connection was lost between the mysql_stmt_prepare() and
       mysql_stmt_execute() C API functions. However,
       mysql_stmt_errno() returned 0, not the corresponding error
       number 2013.
       (Bug#53899: http://bugs.mysql.com/bug.php?id=53899)

     * Queries that used MIN() or MAX() on indexed columns could be
       optimized incorrectly.
       (Bug#53859: http://bugs.mysql.com/bug.php?id=53859)

     * The Lock_time value in the slow query log was negative for
       stored routines.
       (Bug#53191: http://bugs.mysql.com/bug.php?id=53191)

     * The results of some ORDER BY ... DESC queries were sorted
       incorrectly.
       (Bug#51431: http://bugs.mysql.com/bug.php?id=51431)

     * Index Merge between three indexes could return incorrect
       results. (Bug#50389: http://bugs.mysql.com/bug.php?id=50389)

     * Performing large numbers of RENAME TABLE statements caused
       excessive memory use.
       (Bug#47991: http://bugs.mysql.com/bug.php?id=47991)

     * The server could crash with an out of memory error when trying
       to parse a query that was too long to fit in memory. Now the
       parser rejects such queries with an ER_OUT_OF_RESOURCES error.
       (Bug#42064: http://bugs.mysql.com/bug.php?id=42064)

     * Sort-index_merge for join tables other than the first table
       used excessive memory.
       (Bug#41660: http://bugs.mysql.com/bug.php?id=41660)

     * Valgrind warnings in the InnoDB compare_record() function were
       corrected. (Bug#38999: http://bugs.mysql.com/bug.php?id=38999)

     * mysqld could fail during execution when using SSL.
       (Bug#34236: http://bugs.mysql.com/bug.php?id=34236)

     * The behavior of the RPM upgrade installation has changed.
       During an upgrade installation using the RPM packages, if the
       MySQL server is running when the upgrade occurs, the server is
       stopped, the upgrade occurs, and server is restarted. If the
       server is not already running when the RPM upgrade occurs, the
       server is not started at the end of the upgrade. The boot
       scripts for MySQL are installed in the appropriate directories
       in /etc, so the MySQL server will be restarted automatically
       at the next machine reboot.
       (Bug#27072: http://bugs.mysql.com/bug.php?id=27072)

Thanks,
MySQL RE Team

Karen Langford MySQL Release Engineer
Database Group, Oracle.

Options: ReplyQuote


Subject
Views
Written By
Posted
MySQL Community Server 5.1.49 has been released
8763
July 23, 2010 07:55AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.