List:Announcements« Previous MessageNext Message »
From:Sunanda Menon Date:July 19 2010 8:21am
Subject:MySQL Community Server 5.5.5-m3 has been released
View as plain text  
Dear MySQL users,

MySQL Server 5.5.5-m3, a new version of the popular Open Source
Database Management System, has been released.
The "-m3" suffix indicates that these releases belong to the third
milestone. According to our "milestone" release model, also called
"Celosia". You can read more about the release model and the planned
milestones at

The new features in these releases are of beta quality. As with any
other pre-production release, caution should be taken when installing
on production level systems or systems with critical data.

Please note that *downgrading* from these releases to a previous
release series, including MySQL Server 5.5 milestone 2 (Betony)
releases, is not supported.

For production level systems using 5.1, we would like to direct your
attention to the product description of MySQL Enterprise at:

MySQL 5.5 is based on MySQL 5.4, which won't get any further updates.
MySQL 5.5 includes several high-impact changes to address scalability
and performance issues in MySQL Server. These changes exploit advances
in hardware and CPU design and enable better utilization of existing

For an overview of what's new in MySQL 5.5, please see the
section "What Is New in MySQL 5.5" online at

For information on installing MySQL 5.5.5-m3 on
new servers, please see the MySQL installation documentation at

For upgrading from previous MySQL releases, please see the
important upgrade considerations at 

MySQL Server 5.5 is available in source and binary form for a
number of platforms from the "Development Releases" selection
of 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.:

The complete list of all "Bugs Fixed" may be viewed online at


Special note for those of you who build from source:

In MySQL 5.5.5-m3, CMake joins GNU autotools as a build framework for
all platforms. We've previously already used CMake on Windows. Our
existing support for GNU autotools isn't going away just yet, but if
you are so inclined, you can now alternatively use CMake as per the
instructions on the web page linked below. The official packages
for this release are the first to be produced using CMake.
As always, we value your feedback!

Changes in MySQL 5.5.5:

|InnoDB is now the default storage engine, rather than MyISAM in|||  the
regular versions of MySQL. This change has the following consequences:

     * Existing tables are not affected by this change, only new
       tables that are created.

     * Some of the|InnoDB|  option settings also change, so that the
       default configuration represents the best practices for|InnoDB|
       functionality,reliability, and file management:
       |innodb_file_format=Barracuda|  rather than|Antelope|,
       |innodb_strict_mode=TRUE|  rather than|FALSE|, and
       |innodb_file_per_table=TRUE|  rather than|FALSE|.

     * The system tables remain in|MyISAM|  format.

     *|MyISAM|  remains the default storage engine for the embedded version
       of MySQL

     Bugs Fixed:

      * Performance: While looking for the shortest index for a
        covering index scan, the optimizer did not consider the full
        row length for a clustered primary key, as in InnoDB.
        Secondary covering indexes will now be preferred, making full
        table scans less likely.

      * Security Fix: The server failed to check the table name
        argument of a COM_FIELD_LIST command packet for validity and
        compliance to acceptable table name standards. This could be
        exploited to bypass almost all forms of checks for privileges
        and table-level grants by providing a specially crafted table
        name argument to COM_FIELD_LIST.
        In MySQL 5.0 and above, this allowed an authenticated user
        with SELECT privileges on one table to obtain the field
        definitions of any table in all other databases and
        potentially of other MySQL instances accessible from the
        server's file system.
        Additionally, for MySQL version 5.1 and above, an
        authenticated user with DELETE or SELECT privileges on one
        table could delete or read content from any other table in all
        databases on this server, and potentially of other MySQL
        instances accessible from the server's file system.

      * Security Fix: The server was susceptible to a buffer-overflow
        attack due to a failure to perform bounds checking on the
        table name argument of a COM_FIELD_LIST command packet. By
        sending long data for the table name, a buffer is overflown,
        which could be exploited by an authenticated user to inject
        malicious code.

      * Security Fix: Privilege checking for UNINSTALL PLUGIN was
        incorrect. (Bug#51770:,

      * Security Fix: The server could be tricked into reading packets
        indefinitely if it received a packet larger than the maximum
        size of one packet.

      * Incompatible Change: TRUNCATE TABLE did not take an exclusive
        lock on a table if truncation was done by deleting all rows in
        the table. For InnoDB tables, this could break proper
        isolation because InnoDB ended up aborting some granted locks
        when truncating a table. Now an exclusive metadata lock is
        taken before TRUNCATE TABLE can proceed. This guarantees that
        no other transaction is using the table.
        Incompatible change: Truncation using delete no longer fails
        if sql_safe_updates is enabled (this was an undocumented side
        effect). (Bug#42643:

      * Important Change: Replication: It was possible to set
        sql_log_bin with session scope inside a transaction or
        subquery. (Bug#53437:

      * Important Change: Replication: When changing binlog_format or
        binlog_direct_non_transactional_updates, permissions were not
        checked prior to checking the scope and context of the
        variable being changed.
        As a result of this fix, an error is no longer reported
        when---in the context of a transaction or a stored
        function---you try to set a value for a session variable that
        is the same as its previous value, or for a variable whose
        scope is global only.

      * Important Change: Replication: When invoked, CHANGE MASTER TO
        and SET GLOBAL sql_slave_skip_counter now cause information to
        be written to the error log about the slave's state prior to
        execution of the statement. For CHANGE MASTER TO, this
        information includes the previous values for MASTER_HOST,
        GLOBAL sql_slave_skip_counter, this information includes the
        previous values of sql_slave_skip_counter, the group relay log
        name, and the group relay log position.

      * Partitioning: Replication: Attempting to execute LOAD DATA on
        a partitioned MyISAM table while using statement-based logging
        mode caused the master to hang or crash.

      * Partitioning: Replication: The NO_DIR_IN_CREATE server SQL
        mode was not enforced when defining subpartitions. In certain
        cases, this could lead to failures on replication slaves.

      * Partitioning: Rows inserted into a table created using a
        PARTITION BY LIST COLUMNS option referencing multiple columns
        could be inserted into the wrong partition.

      * Partitioning: Partition pruning on RANGE partitioned tables
        did not always work correctly; the last partition was not
        excluded if the range was beyond it (when not using MAXVALUE).
        Now the last partition is not included if the partitioning
        function value is not within the range.

      * Partitioning: Attempting to partition a table using a DECIMAL
        column caused the server to crash; this not supported and is
        now specifically disallowed.

      * Partitioning: ALTER TABLE statements that cause table
        partitions to be renamed or dropped (such as ALTER TABLE ...
        ... REORGANIZE PARTITION) --- when run concurrently with
        queries against the INFORMATION_SCHEMA.PARTITIONS table ---
        could fail, cause the affected partitioned tables to become
        unusable, or both. This was due to the fact that the
        INFORMATION_SCHEMA database ignored the name lock imposed by
        the ALTER TABLE statement on the partitions affected. In
        particular, this led to problems with InnoDB tables, because
        InnoDB would accept the rename operation, but put it in a
        background queue, so that subsequent rename operations failed
        when InnoDB was unable to find the correct partition. Now,
        INFORMATION_SCHEMA honors name locks imposed by ongoing ALTER
        TABLE statements that cause partitions to be renamed or
        dropped. (Bug#50561:
        See also Bug#47343:,

      * Partitioning: The insert_id server system variable was not
        reset following an insert that failed on a partitioned MyISAM
        table having an AUTO_INCREMENT column.

      * Partitioning: Foreign keys are not supported on partitioned
        tables. However, it was possible via an ALTER TABLE statement
        to set a foreign key on a partitioned table; it was also
        possible to partition a table with a single foreign key.

      * Partitioning: When attempting to perform DDL on a partitioned
        table and the table's .par file could not be found, the server
        returned the inaccurate error message Out of memory; restart
        server and try again (needed 2 bytes). Now in such cases, the
        server returns the error Failed to initialize partitions from
        .par file. (Bug#49161:

      * Partitioning: GROUP BY queries performed poorly for some
        partitioned tables. This was due to the block size not being
        set for partitioned tables, thus the keys per block was not
        correct, which could cause such queries to be optimized
        See also Bug#37252:

      * Partitioning: REPAIR TABLE failed for partitioned ARCHIVE
        tables. (Bug#46565:

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

      * Replication: When a CREATE TEMPORARY TABLE ... SELECT
        statement was executed within a transaction that updated only
        transactional engines and was later rolled back (for example,
        due to a deadlock) the changes---including the creation of the
        temporary table---were not written to the binary log, which
        caused subsequent updates to this table to fail on the slave.

      * Replication: When using the statement-based logging format,
        statements that used CONNECTION_ID() were always kept in the
        transaction cache; consequently, nontransactional changes that
        should have been flushed before the transaction were kept in
        the transaction cache.
        This regression was introduced by

      * Replication: In some cases, attempting to update a column with
        a value of an incompatible type resulted in a mismatch between
        master and slave because the column value was set to its
        implicit default value on the master (as expected), but the
        same column on the slave was set to NULL.

      * Replication: When temporary tables were in use, switching the
        binary logging format from STATEMENT to ROW did not take
        effect until all temporary tables were dropped. (The existence
        of temporary tables should prevent switching the format only
        from ROW to STATEMENT from taking effect, not the reverse.)

      * Replication: A buffer overrun in the handling of DATE column
        values could cause mysqlbinlog to fail when reading back logs
        containing certain combinations of DML on a table having a
        DATE column followed by dropping the table.

      * Replication: The failure of a REVOKE statement was logged with
        the wrong error code, causing replication slaves to stop even
        when the failure was expected on the master.

      * -laio missing from embedded libs

      Please see the complete list of changes to MySQL 5.5.5



  (MySQL Release Engineering Team)

MySQL Community Server 5.5.5-m3 has been releasedSunanda Menon19 Jul