List:General Discussion« Previous MessageNext Message »
From:Jonathan Perkin Date:September 21 2009 10:04am
Subject:MySQL Community Server 5.1.39 has been released
View as plain text  
Dear MySQL users,

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

As with MySQL 5.1.38, 5.1.39 includes the InnoDB Plugin version 1.0.4.
This version of the InnoDB Plugin is considered of Beta quality and is
disabled by default.  For more information, including instructions on
how to enable the InnoDB Plugin, please see

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

For information on installing MySQL 5.1.39 on new servers or upgrading
to MySQL 5.1.39 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.1. Changes in MySQL 5.1.39

   Bugs fixed:

     * Partitioning: An INSERT ... SELECT statement on an empty
       partition of a partitioned table failed with ERROR 1030
       (HY000): Got error 124 from storage engine. This issue also
       caused queries run against a partitioned table while a LOAD
       DATA CONCURRENT INFILE statement was in progress to fail with
       the same error. (Bug#46639:
       See also Bug#35845:,

     * Partitioning: A partitioned table having a TIMESTAMP column
       with a default value of CURRENT_TIMESTAMP and this column was
       not defined using an ON UPDATE option, an ALTER TABLE ...
       REORGANIZE PARTITION statement on the table caused the
       TIMESTAMP column value to be set to CURRENT_TIMESTAMP
       regardless. (Bug#46478:

     * Partitioning: Attempting to access a partitioned table when
       partitioning support was disabled in a MySQL server binary
       that had been compiled with partitioning support caused the
       server to crash. (Bug#39893:

     * Partitioning: The use of TO_DAYS() in the partitioning
       expression led to selection failures when the column having
       the date value contained invalid dates. This occurred because
       the function returns NULL in such cases, and the partition
       containing NULL values was pruned away. For example, this
       problem occurred if '2001-02-00' was inserted into a DATE
       column of such a table, and a subsequent query on this table
       used WHERE date_col < '2001-02-00' --- while '2001-01-01' is
       less than '2001-02-00', TO_DAYS('2001-02-00') evaluates as
       NULL, and so the row containing '2001-01-01' was not returned.
       Now, for tables using RANGE or LIST partitioning and having
       TO_DAYS() in the partitioning expression, the NULL partition
       is also scanned instead of being ignored.
       The fix for this issue also corrects misbehavior such that a
       query of the form SELECT * FROM table WHERE date_col <
       date_val on a table partitioned by RANGE or LIST was handled
       as though the server SQL mode included ALLOW_INVALID_DATES
       even if this was not actually part of the server SQL mode at
       the time the query was issued.
       See also Bug#18198:,

     * Replication: Performing a multi-row update of the
       AUTO_INCREMENT column of a transactional table could result in
       an inconsistency between master and slave when there was a
       trigger on the transactional table that updated a
       non-transactional table. When such an update failed on the
       master, no rows were updated on the master, but some rows
       could (erroneously) be updated on the slave.

     * Replication: When using the --replicate-rewrite-db option and
       the database referenced by this option on the master was the
       current database when the connection to the slave was closed,
       any temporary tables existing in this database were not
       properly dropped. (Bug#46861:

     * Replication: When a statement that changed both transactional
       and non-transactional tables failed, the transactional changes
       were automatically rolled back on the master but the slave
       ignored the error and did not roll them back, thus leading to
       inconsistencies between master and slave.
       This issue is fixed by automatically rolling back a statement
       that fails on the slave; however, the transaction is not
       rolled back unless a corresponding ROLLBACK statement is found
       in the relay log file.
       See also Bug#33864:

     * Replication: When slave_transaction_retries is set, a
       statement that replicates, but is then rolled back due to a
       deadlock on the slave, should be retried. However, in certain
       cases, replication was stopped with error 1213 (Deadlock found
       when trying to get lock; try restarting transaction) instead,
       even when this variable was set.

     * Replication: The binary logging behavior (and thus, the
       replication behavior) of CREATE DATABASE IF NOT EXISTS, CREATE
       consistent among these statements, nor with that of DROP
       EXISTS: A DROP ... IF EXISTS statement is always logged even
       if the database object named in the statement does not exist.
       However, of the CREATE ... IF NOT EXISTS statements, only the
       CREATE EVENT IF NOT EXISTS statement was logged when the
       database object named in the statement already existed.
       Now, every CREATE ... IF NOT EXISTS statement is written to
       the binary log (and thus replicated), whether the database
       object named in the statement exists or not. For more
       information, see Section, "Replication of CREATE ...
       IF NOT EXISTS Statements."
       Exception.  Replication and logging of CREATE TABLE IF NOT
       EXISTS ... SELECT continues to be handled according to
       existing rules. See Section, "Replication of CREATE
       TABLE ... SELECT Statements," for more information.

     * Replication: When using statement-based replication,
       database-level character sets were not always honored by the
       replication SQL thread. This could cause data inserted on the
       master using LOAD DATA to be replicated using the wrong
       character set.

       This was not an issue when using row-based replication.

     * Replication: In some cases, a STOP SLAVE statement could cause
       the replication slave to crash. This issue was specific to
       MySQL on Windows or Macintosh platforms.

     * Replication: Creating a scheduled event whose DEFINER clause
       was either set to CURRENT_USER or not set explicitly caused
       the master and the slave to become inconsistent. This issue
       stems from the fact that, in both cases, the DEFINER is set to
       the CURRENT_USER of the current thread. (On the master, the
       CURRENT_USER is the mysqld user; on the slave, the
       CURRENT_USER is empty.)
       This behavior has been modified as follows:

          + If CURRENT_USER is used as the DEFINER, it is replaced
            with the value of CURRENT_USER before the CREATE EVENT
            statement is written to the binary log.

          + If the definer is not set explicitly, a DEFINER clause
            using the value of CURRENT_USER is added to the CREATE
            EVENT statement before it is written to the binary log.
       See also Bug#42217:

     * Replication: When using the statement-based logging format,
       the only possible safe combination of transactional and
       non-transactional statements within the same transaction is to
       perform any updates on non-transactional tables (such as
       MyISAM tables) first, before updating any transactional tables
       (such as those using the InnoDB storage engine). This is due
       to the fact that, although a modification made to a
       non-transactional table is immediately visible to other
       connections, the update is not immediately written to the
       binary log, which can lead to inconsistencies between master
       and slave. (Other combinations may hide a causal dependency,
       thus making it impossible to write statements updating
       non-transactional tables to the binary log in the correct
       However, in some cases, this situation was not handled
       properly, and the determination whether a given statement was
       safe or not under these conditions was not always correct. In
       particular, a multi-table update that affected both
       transactional and non-transactional tables or a statement
       modifying data in a non-transactional table having a trigger
       that operated on a transactional table (or the reverse) was
       not determined to be unsafe when it should have been.
       With this fix, the following determinations regarding
       replication safety are made when combining updates to
       transactional and non-transactional tables within the same
       transaction in statement-based logging mode:

         1. Any statement modifying data in a non-transactional table
            within a given transaction is considered safe if it is
            issued prior to any data modification statement accessing
            a transactional table within the same transaction.

         2. A statement that updates transactional tables only is
            always considered safe.

         3. A statement affecting both transactional and
            non-transactional tables within a transaction is always
            considered unsafe. It is not necessary that both tables
            be modified for this to be true; for example, a statement
            such as INSERT INTO innodb_table SELECT * FROM
            myisam_table is also considered unsafe.

       The current fix is valid only when using statement-based
       logging mode; we plan to address similar issues occurring when
       using the MIXED or ROW format in a future MySQL release.

     * Stack overflow checking did not account for the size of the
       structure stored in the heap.

     * In queries for which the loose index scan access method was
       chosen, using a condition of the form col_name rather than the
       equivalent col_name <> 0 caused an assertion failure.

     * Killing a query that was performing a sort could result in a
       memory leak. (Bug#45962:

     * Truncation of DECIMAL values could lead to assertion failures;
       for example, when deducing the type of a table column from a
       literal DECIMAL value.

     * Bulk insert performance could suffer with large
       read_buffer_size values.

     * A buffer overflow could occur during handling of IS NULL
       ranges. (Bug#37044:

     * mysqladmin --wait ping crashed on Windows systems.

Jonathan Perkin, Release Engineering, MySQL
Database Technology Group, Sun Microsystems
MySQL Community Server 5.1.39 has been releasedJonathan Perkin21 Sep