MySQL Lists are EOL. Please join:

List:Announcements« Previous MessageNext Message »
From:Joerg Bruehe Date:February 26 2010 5:52pm
Subject:MySQL 5.5.2-m2 has been released
View as plain text  
Dear MySQL users,

MySQL Server 5.5.2-m2, a new version of the popular Open Source
Database Management System, has been released.

The "-m2" suffix tells this belongs to the second milestone according
to our "milestone" release model, also called "Betony".
You can read more about the release model and the planned milestones at

The new features in this release 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.
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.
So 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" below, or view it online at

For information on installing MySQL 5.5.2-m2 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.:

You will remember there was a security issue in yaSSL (the SSL
library used by MySQL) which was reported only while the publishing
process of 5.5.1-m2 was already running:
One of the changes in 5.5.2-m2 over 5.5.1-m2 is the fix for that
security issue.

Following the "What Is New" section, this mail lists the changes
in the MySQL source code of MySQL 5.5.2-m2.
The list of all "Bugs Fixed" may also be viewed online at


On behalf of the MySQL Build Team at Sun Microsystems:
Jörg Brühe,
Senior Production Engineer


What Is New in MySQL 5.5

The following features have been added to MySQL 5.5:

 * Support for an interface for semisynchronous replication:
   A commit performed on the master side blocks before returning
   to the session that performed the transaction until at least
   one slave acknowledges that it has received and logged the events
   for the transaction.
   Semisynchronous replication is implemented through an optional
   plugin component. See Section 16.2.8, "Semisynchronous Replication"

 * Support for the SQL standard SIGNAL and RESIGNAL statements.
   See Section 12.8.8, "SIGNAL and RESIGNAL".

 * Enhancements to XML functionality, including a new LOAD XML

 * Two new types of user-defined partitioning are supported:
   RANGE COLUMNS partitioning is an extension to RANGE partitioning;
   LIST COLUMNS partitioning is an extension to LIST partitioning.
   Each of these extensions provides two enhancements to MySQL
   partitioning capabilities:

   1. It is possible to define partitioning ranges or lists based on
      DATE, DATETIME, or string values (such as CHAR or VARCHAR).

      You can also define ranges or lists based on multiple column
      values when partitioning tables by RANGE COLUMNS or LIST COLUMNS,
      respectively. Such a range or list may refer to up to 16 columns.

   2. For tables defined using these partitioning types, partition
      pruning can now optimize queries with WHERE conditions that use
      multiple comparisons between (different) column values and
      constants, such as
          a = 10 AND b > 5 or a < "2005-11-25" AND b = 10 AND c = 50.

      For more information, see Section 17.2.1, "RANGE Partitioning",
      and Section 17.2.2, "LIST Partitioning".

 * It is now possible to delete all rows from one or more partitions
   of a partitioned table using the ALTER TABLE ... TRUNCATE
   PARTITION statement. Executing the statement deletes rows without
   affecting the structure of the table. The partitions named in the
   TRUNCATE PARTITION clause do not have to be contiguous.

 * Key caches are now supported for indexes on partitioned MyISAM
   tables, using the CACHE INDEX and LOAD INDEX INTO CACHE statements.
   In addition, a key cache can be defined for and loaded with indexes
   from an entire partitioned table, or for one or more partitions.
   In the latter case, the partitions are not required to be contiguous.

 * The TO_SECONDS() function is added. This function converts a date or
   datetime expression to a number of seconds since the year 0. You may
   use this function in partitioning expressions, and partition pruning
   is supported for table defined using such expressions.

The following constructs are deprecated and will be removed in a future
MySQL release. Where alternatives are shown, applications should be
updated to use them.

 * The table_type system variable (use storage_engine).

   The TYPE table option to specify the storage engine for


 * The log_bin_trust_routine_creators variable
   (use log_bin_trust_function_creators).

 * TIMESTAMP(N): The ability to specify a display width of N
   (use without N).

   (use SHOW ENGINE INNODB STATUS for both of these).


 * The SHOW PLUGIN SQL statement (use SHOW PLUGINS).

 * The BACKUP TABLE and the RESTORE TABLE SQL statements.

 * The --master-xxx server options to set replication parameters
   (use the CHANGE MASTER TO statement instead):
   --master-host, --master-user, --master-password, --master-port,
   --master-connect-retry, --master-ssl, --master-ssl-ca,
   --master-ssl-capath, --master-ssl-cert, --master-ssl-cipher,


Changes in MySQL 5.5.2:

InnoDB Plugin Notes:

  * This release includes InnoDB Plugin 1.0.6. This version is
    considered of Release Candidate (RC) quality.

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:

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

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

  * Security Fix: For servers built with yaSSL, a preauthorization
    buffer overflow could cause memory corruption or a server
    crash. We thank Evgeny Legerov from Intevydis for providing us
    with a proof-of-concept script that allowed us to reproduce
    this bug. (Bug#50227:,

  * Incompatible Change: In plugin.h, the MYSQL_REPLICATION_PLUGIN
    symbol was out of synchrony with its value in MySQL 6.0
    because the lower-valued MYSQL_AUDIT_PLUGIN was not present.
    To correct this, MYSQL_AUDIT_PLUGIN has been added in MySQL
    5.5, changing the value of MYSQL_REPLICATION_PLUGIN from 5 to

    6. Attempts to load the audit plugin produce an error occurs
    because only the MYSQL_AUDIT_PLUGIN symbol was added, not the
    audit plugin itself. This error will go away when the audit
    plugin is added to MySQL 5.5. Replication plugins from earlier
    5.5.x releases must be recompiled against the current release
    before they will work with the current release.

  * Important Change: Replication: The RAND() function is now
    marked as unsafe for statement-based replication. Using this
    function now generates a warning when binlog_format=STATEMENT
    and causes the the format to switch to row-based logging when
    This change is being introduced because, when RAND() was
    logged in statement mode, the seed was also written to the
    binary log, so the replication slave generated the same
    sequence of random numbers as was generated on the master.
    While this could make replication work in some cases, the
    order of affected rows was still not guaranteed when this
    function was used in statements that could update multiple
    rows, such as UPDATE or INSERT ... SELECT; if the master and
    the slave retrieved rows in different order, they began to
    diverge. (Bug#49222:

  * Partitioning: When used on partitioned tables, the
    records_in_range handler call checked all partitions, rather
    than the unpruned partitions only.
    See also Bug#37252:,

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

  * Replication: With semisynchronous replication, memory
    allocated for handling transactions could be freed while still
    in use, resulting in a server crash.

  * 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: A LOAD DATA INFILE statement that loaded data
    into a table having a column name that had to be escaped (such
    as `key` INT) caused replication to fail when logging in mixed
    or statement mode. In such cases, the master wrote the LOAD
    DATA event into the binary log without escaping the column
    names. (Bug#49479:
    See also Bug#47927:

  * 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: Spatial data types caused row-based replication
    to crash. (Bug#48776:

  * Replication: When using row-based logging, the statement
    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.

  * Replication: Manually removing entries from the binary log
    index file on a replication master could cause the server to
    repeatedly send the same binary log file to slaves.

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

  * SPATIAL indexes were allowed on columns with non-spatial data
    types, resulting in a server crash for subsequent table
    inserts. (Bug#50574:

  * Index prefixes could be specified with a length greater than
    the associated column, resulting in a server crash for
    subsequent table inserts.

  * Use of loose index scan optimization for an aggregate function
    with DISTINCT (for example, COUNT(DISTINCT)) could produce
    incorrect results.

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

  * Within a stored routine, selecting the result of CONCAT_WS()
    with a routine parameter argument into a user variable could
    return incorrect results.

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

  * EXPLAIN EXTENDED UNION ... ORDER BY caused a crash when the
    ORDER BY referred to a nonconstant or full-text function or a
    subquery. (Bug#49734:

  * Some prepared statements could raise an assertion when

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

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

  * Several strmake() calls had an incorrect length argument (too
    large by one).

  * On Fedora 12, strmov() did not guarantee correct operation for
    overlapping source and destination buffer. Calls were fixed to
    use an overlap-safe version instead.

  * With one thread waiting for a lock on a table, if another
    thread dropped the table and created a new table with the same
    name and structure, the first thread would not notice that the
    table had been re-created and would try to used cached
    metadata that belonged to the old table but had been freed.

  * If an invocation of a stored procedure failed in the
    table-open stage, subsequent invocations that did not fail in
    that stage could cause a crash.

  * A crash occurred when a user variable that was assigned to a
    subquery result was used as a result field in a SELECT
    statement with aggregate functions.

  * When the mysql client was invoked with the --vertical option,
    it ignored the --skip-column-names option.

  * If EXPLAIN encountered an error in the query, a memory leak
    occurred. (Bug#45989:

  * A race condition on the privilege hash tables allowed one
    thread to try to delete elements that had already been deleted
    by another thread. A consequence was that SET PASSWORD or
    FLUSH PRIVILEGES could cause a crash.

  * 1) In rare cases, if a thread was interrupted during a FLUSH
    PRIVILEGES operation, a debug assertion occurred later due to
    improper diagnostic area setup. 2) A KILL operation could
    cause a console error message referring to a diagnostic area
    state without first ensuring that the state existed.

  * ALTER TABLE with both DROP COLUMN and ADD COLUMN clauses could
    crash or lock up the server.

  * The Table_locks_waited waited variable was not incremented in
    the cases that a lock had to be waited for but the waiting
    thread was killed or the request was aborted.

Joerg Bruehe,  MySQL Build Team,  Joerg.Bruehe@stripped
Sun Microsystems GmbH,   Komturstraße 18a,   D-12099 Berlin
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels
Vorsitzender des Aufsichtsrates: Martin Haering     Muenchen: HRB161028

MySQL 5.5.2-m2 has been releasedJoerg Bruehe26 Feb