MySQL Lists are EOL. Please join:

List:Announcements« Previous MessageNext Message »
From:Karen Langford Date:February 18 2010 7:56pm
Subject:MySQL Community Server 5.1.44 has been released
View as plain text  
Dear MySQL users,

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

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

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

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

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.:

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

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



C.1.2. Changes in MySQL 5.1.44

    InnoDB Plugin Notes:

      * This release includes InnoDB Plugin 1.0.6. This version is
        considered of Release Candidate (RC) quality.
        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.

    Functionality added or changed:

      * Replication: Introduced the
        --binlog-direct-non-transactional-updates server option. This
        option causes updates using the statement-based logging format
        to tables using non-transactional engines to be written
        directly to the binary log, rather than to the transaction
        Before using this option, be certain that you have no
        dependencies between transactional and non-transactional
        tables. A statement that both selects from an InnoDB table and
        inserts into a MyISAM table is an example of such a
        dependency. For more information, see Section,
        "Binary Log Options and Variables."
        See also Bug#28976:,

    Bugs fixed:

      * Partitioning: When an ALTER TABLE ... REORGANIZE PARTITION
        statement on an InnoDB table failed due to
        innodb_lock_wait_timeout expiring while waiting for a lock,
        InnoDB did not clean up any temporary files or tables which it
        had created. Attempting to reissue the ALTER TABLE statement
        following the timeout could lead to storage engine errors, or
        possibly a crash of the server.

      * Replication: In some cases, inserting into a table with many
        columns could cause the binary log to become corrupted.
        See also Bug#42749:

      * Replication: When using row-based replication, setting a BIT
        or CHAR column of a MyISAM table to NULL, then trying to
        delete from the table, caused the slave to fail with the error
        Can't find record in table.

      * Replication: When logging in row-based mode, DDL statements
        are actually logged as statements; however, statements that
        affected temporary tables and followed DDL statements failed
        to reset the binary log format to ROW, with the result that
        these statements were logged using the statement-based format.
        Now the state of binlog_format is restored after a DDL
        statement has been written to the binary log.

      * Replication: When using row-based logging, the statement
        CREATE TABLE t IF NOT EXIST ... SELECT was logged as CREATE
        TEMPORARY TABLE t IF NOT EXIST ... SELECT when t already
        existed as a temporary table. This was caused by the fact that
        the temporary table was opened and the results of the SELECT
        were inserted into it when a temporary table existed and had
        the same name.
        Now, when this statement is executed, t is created as a base
        table, the results of the SELECT are inserted into it --- even
        if there already exists a temporary table having the same name
        --- and the statement is logged correctly.
        See also Bug#47442:

      * Replication: Due to a change in the size of event
        representations in the binary log, when replicating from a
        MySQL 4.1 master to a slave running MySQL 5.0.60 or later, the
        START SLAVE UNTIL statement did not function correctly,
        stopping at the wrong position in the log. Now the slave
        detects that the master is using the older version of the
        binary log format, and corrects for the difference in event
        size, so that the slave stops in the correct position.

      * The SSL certificates in the test suite were about to expire.
        They have been updated with expiration dates in the year 2015.

      * The printstack function does not exist on Solaris 8 or
        earlier, which would lead to a compilation failure.

      * A user could see tables in INFORMATION_SCHEMA.TABLES without
        appropriate privileges for them.

      * Debug output for join structures was garbled.

      * The filesort sorting method applied to a CHAR(0) column could
        lead to a server crash.

      * sql_buffer_result had an effect on non-SELECT statements,
        contrary to the documentation.

      * In some cases a subquery need not be evaluated because it
        returns only aggregate values that can be calculated from
        table metadata. This sometimes was not handled by the
        enclosing subquery, resulting in a server crash.

      * The method for comparing INFORMATION_SCHEMA names and database
        names was nonoptimal and an improvement was made: When the
        database name length is already known, a length check is made
        first and content comparison skipped if the lengths are
        unequal. (Bug#49501:

      * The MD5() and SHA1() functions had excessive overhead for
        short strings.

      * Mixing full-text searches and row expressions caused a crash.

      * Creating or dropping a table with 1023 transactions active
        caused an assertion failure.

      * now recognizes the MTR_TESTCASE_TIMEOUT,
        environment variables. If they are set, their values are used
        to set the --testcase-timeout, --suite-timeout,
        --shutdown-timeout, and --start-timeout options, respectively.


Hery Ramilison, Karen Langford, MySQL Release Engineers
Database Group, Sun Microsystem Inc.

MySQL Community Server 5.1.44 has been releasedKaren Langford18 Feb