← Back to team overview

ius-coredev team mailing list archive

[Bug 650438] [NEW] MySQL 5.1.51 Source Update

 

Public bug reported:

Dear MySQL users,

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

Enjoy!

=======================================================================

C.1.1. Changes in MySQL 5.1.51 (10 September 2010)

   InnoDB Notes:

     * InnoDB Plugin has been upgraded to version 1.0.12. This
       version is considered of General Availability (GA) quality.
       In this release, the InnoDB Plugin is included in source and
       binary distributions, except RHEL3, RHEL4, SuSE 9 (x86,
       x86_64, ia64), generic Linux RPM packages, and any builds
       produced with the icc compiler. It also does not work for
       FreeBSD 6 and HP-UX or for Linux on generic ia64.

   Bugs fixed:

     * Incompatible Change: Replication: As of MySQL 5.5.6, handling
       of CREATE TABLE IF NOT EXISTS ... SELECT statements has been
       changed for the case that the destination table already
       exists:

          + Previously, for CREATE TABLE IF NOT EXISTS ... SELECT,
            MySQL produced a warning that the table exists, but
            inserted the rows and wrote the statement to the binary
            log anyway. By contrast, CREATE TABLE ... SELECT (without
            IF NOT EXISTS) failed with an error, but MySQL inserted
            no rows and did not write the statement to the binary
            log.

          + MySQL now handles both statements the same way when the
            destination table exists, in that neither statement
            inserts rows or is written to the binary log. The
            difference between them is that MySQL produces a warning
            when IF NOT EXISTS is present and an error when it is
            not.
       This change in handling of IF NOT EXISTS results in an
       incompatibility for statement-based replication from a MySQL
       5.1 master with the original behavior and a MySQL 5.5 slave
       with the new behavior. Suppose that CREATE TABLE IF NOT EXISTS
       ... SELECT is executed on the master and the destination table
       exists. The result is that rows are inserted on the master but
       not on the slave. (Row-based replication does not have this
       problem.)
       To address this issue, statement-based binary logging for
       CREATE TABLE IF NOT EXISTS ... SELECT is changed in MySQL 5.1
       as of 5.1.51:

          + If the destination table does not exist, there is no
            change: The statement is logged as is.

          + If the destination table does exist, the statement is
            logged as the equivalent pair of CREATE TABLE IF NOT
            EXISTS and INSERT ... SELECT statements. (If the SELECT
            in the original statement is preceded by IGNORE or
            REPLACE, the INSERT becomes INSERT IGNORE or REPLACE,
            respectively.)
       This change provides forward compatibility for statement-based
       replication from MySQL 5.1 to 5.5 because when the destination
       table exists, the rows will be inserted on both the master and
       slave. To take advantage of this compatibility measure, the
       5.1 server must be at least 5.1.51 and the 5.5 server must be
       at least 5.5.6.
       To upgrade an existing 5.1-to-5.5 replication scenario,
       upgrade the master first to 5.1.51 or higher. Note that this
       differs from the usual replication upgrade advice of upgrading
       the slave first.
       A workaround for applications that wish to achieve the
       original effect (rows inserted regardless of whether the
       destination table exists) is to use CREATE TABLE IF NOT EXISTS
       and INSERT ... SELECT statements rather than CREATE TABLE IF
       NOT EXISTS ... SELECT statements.
       Along with the change just described, the following related
       change was made: Previously, if an existing view was named as
       the destination table for CREATE TABLE IF NOT EXISTS ...
       SELECT, rows were inserted into the underlying base table and
       the statement was written to the binary log. As of MySQL
       5.1.51 and 5.5.6, nothing is inserted or logged.
       (Bug#47442: http://bugs.mysql.com/bug.php?id=47442,
       Bug#47132: http://bugs.mysql.com/bug.php?id=47132,
       Bug#48814: http://bugs.mysql.com/bug.php?id=48814,
       Bug#49494: http://bugs.mysql.com/bug.php?id=49494)

     * Incompatible Change: Previously, if you flushed the logs using
       FLUSH LOGS or mysqladmin flush-logs and mysqld was writing the
       error log to a file (for example, if it was started with the
       --log-error option), it renamed the current log file with the
       suffix -old, then created a new empty log file. This had the
       problem that a second log-flushing operation thus caused the
       original error log file to be lost unless you saved it under a
       different name. For example, you could use the following
       commands to save the file:
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory
       To avoid the preceding file-loss problem, renaming no longer
       occurs. The server merely closes and reopens the log file. To
       rename the file, you can do so manually before flushing. Then
       flushing the logs reopens a new file with the original file
       name. For example, you can rename the file and create a new
       one using the following commands:
shell> mv host_name.err host_name.err-old
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory
       (Bug#29751: http://bugs.mysql.com/bug.php?id=29751)

     * Partitioning: When the storage engine used to create a
       partitioned table was disabled, attempting to drop the table
       caused the server to crash.
       (Bug#46086: http://bugs.mysql.com/bug.php?id=46086)

     * If a view was named as the destination table for CREATE TABLE
       ... SELECT, the server produced a warning whether or not IF
       NOT EXISTS was used. Now it produces a warning only when IF
       NOT EXISTS is used, and an error otherwise.
       (Bug#55777: http://bugs.mysql.com/bug.php?id=55777)

     * The CHECK TABLE command could cause a time-consuming
       verification of the InnoDB adaptive hash index memory
       structure. Now this extra checking is only performed in
       binaries built for debugging.
       (Bug#55716: http://bugs.mysql.com/bug.php?id=55716)

     * After the fix for
       Bug#39653: http://bugs.mysql.com/bug.php?id=39653, the
       shortest available secondary index was used for full table
       scans. The primary clustered key was used only if no secondary
       index could be used. However, when the chosen secondary index
       includes all columns of the table being scanned, it is better
       to use the primary index because the amount of data to scan is
       the same but the primary index is clustered. This is now taken
       into account.
       (Bug#55656: http://bugs.mysql.com/bug.php?id=55656)

     * (Bug#55627: http://bugs.mysql.com/bug.php?id=55627)

     * The server was not checking for errors generated during the
       execution of Item::val_xxx() methods when copying data to a
       group, order, or distinct temp table's row.
       (Bug#55580: http://bugs.mysql.com/bug.php?id=55580)

     * ORDER BY clauses that included user variable expressions could
       cause a debug assertion to be raised.
       (Bug#55565: http://bugs.mysql.com/bug.php?id=55565)

     * Queries involving predicates of the form const NOT BETWEEN
       not_indexed_column AND indexed_column could return incorrect
       data due to incorrect handling by the range optimizer.
       (Bug#54802: http://bugs.mysql.com/bug.php?id=54802)

     * MIN() or MAX() with a subquery argument could raise a debug
       assertion for debug builds or return incorrect data for
       nondebug builds.
       (Bug#54465: http://bugs.mysql.com/bug.php?id=54465)

     * INFORMATION_SCHEMA plugins with no deinit() method resulted in
       a memory leak.
       (Bug#54253: http://bugs.mysql.com/bug.php?id=54253)

     * After ALTER TABLE was used on a temporary transactional table
       locked by LOCK TABLES, any later attempts to execute LOCK
       TABLES or UNLOCK TABLES caused a server crash.
       (Bug#54117: http://bugs.mysql.com/bug.php?id=54117)

     * INSERT IGNORE INTO ... SELECT statements could cause a debug
       assertion to be raised.
       (Bug#54106: http://bugs.mysql.com/bug.php?id=54106)

     * The fix for Bug#30234: http://bugs.mysql.com/bug.php?id=30234
       caused the server to reject the DELETE tbl_name.* ... Access
       compatibility syntax for multiple-table DELETE statements.
       (Bug#53034: http://bugs.mysql.com/bug.php?id=53034)

     * Enumeration plugin variables were subject to a type casting
       error, causing inconsistent results between different
       platforms. (Bug#42144: http://bugs.mysql.com/bug.php?id=42144)

     * A PKG install on Solaris put some files in incorrect
       locations. (Bug#31058: http://bugs.mysql.com/bug.php?id=31058)

Thanks,
MySQL RE Team

Karen Langford  MySQL Release Engineer
Database Group, Oracle.

** Affects: ius
     Importance: Medium
         Status: New

** Affects: ius/ius-el5-stable
     Importance: Medium
         Status: New

** Also affects: ius/ius-el5-stable
   Importance: Undecided
       Status: New

** Changed in: ius/ius-el5-stable
    Milestone: None => el5-2010-10-05

** Changed in: ius/ius-el5-stable
   Importance: Undecided => Medium

-- 
MySQL 5.1.51 Source Update
https://bugs.launchpad.net/bugs/650438
You received this bug notification because you are a member of IUS Core
Development, which is subscribed to IUS Community Project.

Status in IUS Community Project: New
Status in IUS Community Project ius-el5-stable series: New

Bug description:
Dear MySQL users,

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

Enjoy!

=======================================================================

C.1.1. Changes in MySQL 5.1.51 (10 September 2010)

   InnoDB Notes:

     * InnoDB Plugin has been upgraded to version 1.0.12. This
       version is considered of General Availability (GA) quality.
       In this release, the InnoDB Plugin is included in source and
       binary distributions, except RHEL3, RHEL4, SuSE 9 (x86,
       x86_64, ia64), generic Linux RPM packages, and any builds
       produced with the icc compiler. It also does not work for
       FreeBSD 6 and HP-UX or for Linux on generic ia64.

   Bugs fixed:

     * Incompatible Change: Replication: As of MySQL 5.5.6, handling
       of CREATE TABLE IF NOT EXISTS ... SELECT statements has been
       changed for the case that the destination table already
       exists:

          + Previously, for CREATE TABLE IF NOT EXISTS ... SELECT,
            MySQL produced a warning that the table exists, but
            inserted the rows and wrote the statement to the binary
            log anyway. By contrast, CREATE TABLE ... SELECT (without
            IF NOT EXISTS) failed with an error, but MySQL inserted
            no rows and did not write the statement to the binary
            log.

          + MySQL now handles both statements the same way when the
            destination table exists, in that neither statement
            inserts rows or is written to the binary log. The
            difference between them is that MySQL produces a warning
            when IF NOT EXISTS is present and an error when it is
            not.
       This change in handling of IF NOT EXISTS results in an
       incompatibility for statement-based replication from a MySQL
       5.1 master with the original behavior and a MySQL 5.5 slave
       with the new behavior. Suppose that CREATE TABLE IF NOT EXISTS
       ... SELECT is executed on the master and the destination table
       exists. The result is that rows are inserted on the master but
       not on the slave. (Row-based replication does not have this
       problem.)
       To address this issue, statement-based binary logging for
       CREATE TABLE IF NOT EXISTS ... SELECT is changed in MySQL 5.1
       as of 5.1.51:

          + If the destination table does not exist, there is no
            change: The statement is logged as is.

          + If the destination table does exist, the statement is
            logged as the equivalent pair of CREATE TABLE IF NOT
            EXISTS and INSERT ... SELECT statements. (If the SELECT
            in the original statement is preceded by IGNORE or
            REPLACE, the INSERT becomes INSERT IGNORE or REPLACE,
            respectively.)
       This change provides forward compatibility for statement-based
       replication from MySQL 5.1 to 5.5 because when the destination
       table exists, the rows will be inserted on both the master and
       slave. To take advantage of this compatibility measure, the
       5.1 server must be at least 5.1.51 and the 5.5 server must be
       at least 5.5.6.
       To upgrade an existing 5.1-to-5.5 replication scenario,
       upgrade the master first to 5.1.51 or higher. Note that this
       differs from the usual replication upgrade advice of upgrading
       the slave first.
       A workaround for applications that wish to achieve the
       original effect (rows inserted regardless of whether the
       destination table exists) is to use CREATE TABLE IF NOT EXISTS
       and INSERT ... SELECT statements rather than CREATE TABLE IF
       NOT EXISTS ... SELECT statements.
       Along with the change just described, the following related
       change was made: Previously, if an existing view was named as
       the destination table for CREATE TABLE IF NOT EXISTS ...
       SELECT, rows were inserted into the underlying base table and
       the statement was written to the binary log. As of MySQL
       5.1.51 and 5.5.6, nothing is inserted or logged.
       (Bug#47442: http://bugs.mysql.com/bug.php?id=47442,
       Bug#47132: http://bugs.mysql.com/bug.php?id=47132,
       Bug#48814: http://bugs.mysql.com/bug.php?id=48814,
       Bug#49494: http://bugs.mysql.com/bug.php?id=49494)

     * Incompatible Change: Previously, if you flushed the logs using
       FLUSH LOGS or mysqladmin flush-logs and mysqld was writing the
       error log to a file (for example, if it was started with the
       --log-error option), it renamed the current log file with the
       suffix -old, then created a new empty log file. This had the
       problem that a second log-flushing operation thus caused the
       original error log file to be lost unless you saved it under a
       different name. For example, you could use the following
       commands to save the file:
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory
       To avoid the preceding file-loss problem, renaming no longer
       occurs. The server merely closes and reopens the log file. To
       rename the file, you can do so manually before flushing. Then
       flushing the logs reopens a new file with the original file
       name. For example, you can rename the file and create a new
       one using the following commands:
shell> mv host_name.err host_name.err-old
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory
       (Bug#29751: http://bugs.mysql.com/bug.php?id=29751)

     * Partitioning: When the storage engine used to create a
       partitioned table was disabled, attempting to drop the table
       caused the server to crash.
       (Bug#46086: http://bugs.mysql.com/bug.php?id=46086)

     * If a view was named as the destination table for CREATE TABLE
       ... SELECT, the server produced a warning whether or not IF
       NOT EXISTS was used. Now it produces a warning only when IF
       NOT EXISTS is used, and an error otherwise.
       (Bug#55777: http://bugs.mysql.com/bug.php?id=55777)

     * The CHECK TABLE command could cause a time-consuming
       verification of the InnoDB adaptive hash index memory
       structure. Now this extra checking is only performed in
       binaries built for debugging.
       (Bug#55716: http://bugs.mysql.com/bug.php?id=55716)

     * After the fix for
       Bug#39653: http://bugs.mysql.com/bug.php?id=39653, the
       shortest available secondary index was used for full table
       scans. The primary clustered key was used only if no secondary
       index could be used. However, when the chosen secondary index
       includes all columns of the table being scanned, it is better
       to use the primary index because the amount of data to scan is
       the same but the primary index is clustered. This is now taken
       into account.
       (Bug#55656: http://bugs.mysql.com/bug.php?id=55656)

     * (Bug#55627: http://bugs.mysql.com/bug.php?id=55627)

     * The server was not checking for errors generated during the
       execution of Item::val_xxx() methods when copying data to a
       group, order, or distinct temp table's row.
       (Bug#55580: http://bugs.mysql.com/bug.php?id=55580)

     * ORDER BY clauses that included user variable expressions could
       cause a debug assertion to be raised.
       (Bug#55565: http://bugs.mysql.com/bug.php?id=55565)

     * Queries involving predicates of the form const NOT BETWEEN
       not_indexed_column AND indexed_column could return incorrect
       data due to incorrect handling by the range optimizer.
       (Bug#54802: http://bugs.mysql.com/bug.php?id=54802)

     * MIN() or MAX() with a subquery argument could raise a debug
       assertion for debug builds or return incorrect data for
       nondebug builds.
       (Bug#54465: http://bugs.mysql.com/bug.php?id=54465)

     * INFORMATION_SCHEMA plugins with no deinit() method resulted in
       a memory leak.
       (Bug#54253: http://bugs.mysql.com/bug.php?id=54253)

     * After ALTER TABLE was used on a temporary transactional table
       locked by LOCK TABLES, any later attempts to execute LOCK
       TABLES or UNLOCK TABLES caused a server crash.
       (Bug#54117: http://bugs.mysql.com/bug.php?id=54117)

     * INSERT IGNORE INTO ... SELECT statements could cause a debug
       assertion to be raised.
       (Bug#54106: http://bugs.mysql.com/bug.php?id=54106)

     * The fix for Bug#30234: http://bugs.mysql.com/bug.php?id=30234
       caused the server to reject the DELETE tbl_name.* ... Access
       compatibility syntax for multiple-table DELETE statements.
       (Bug#53034: http://bugs.mysql.com/bug.php?id=53034)

     * Enumeration plugin variables were subject to a type casting
       error, causing inconsistent results between different
       platforms. (Bug#42144: http://bugs.mysql.com/bug.php?id=42144)

     * A PKG install on Solaris put some files in incorrect
       locations. (Bug#31058: http://bugs.mysql.com/bug.php?id=31058)

Thanks,
MySQL RE Team

Karen Langford  MySQL Release Engineer
Database Group, Oracle.





Follow ups

References