List:Announcements« Previous MessageNext Message »
From:Joerg Bruehe Date:September 19 2010 7:41pm
Subject:MySQL Community Server 5.5.6-rc has been released
View as plain text  
Dear MySQL users,

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

The "-rc" suffix indicates this is a "release candidate". When there is
sufficient positive feedback, there will be a "GA" (production quality)
version of 5.5. From then on, MySQL 5.5 will receive production bug
fixing support.

If you are running a MySQL 5.1 production level system, we would like to
direct your attention to the product description of MySQL Enterprise at:

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

The new features in these releases are above 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 information on installing MySQL 5.5.6-rc 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:

Since MySQL 5.5.5-m3, CMake joins GNU autotools as a build framework for
all platforms. We've already used CMake on Windows only. Our existing
support for GNU autotools isn't going away just yet, but you can now
alternatively use CMake as per the instructions on this web page:

The official packages for this release have been produced using CMake.
As always, we value your feedback!


Changes in MySQL 5.5.6:

Functionality added or changed:

  * Incompatible Change: The SHA2() function now returns a
    character string with the connection character set and
    collation. Previously, it returned a binary string. This
    is the same change made for several other encryption
    functions in MySQL 5.5.3.

  * Overhead for the Performance Schema interface was

Bugs fixed:

  * Security Fix: After changing the values of the
    innodb_file_format or innodb_file_per_table configuration
    parameters, DDL statements could cause a server crash.

  * Security Fix: Joins involving a table with a unique SET
    column could cause a server crash.

  * Security Fix: Incorrect handling of NULL arguments could
    lead to a crash for IN() or CASE operations when NULL
    arguments were either passed explicitly as arguments (for
    IN()) or implicitly generated by the WITH ROLLUP modifier
    (for IN() and CASE).

  * Security Fix: A malformed argument to the BINLOG
    statement could result in Valgrind warnings or a server

  * Security Fix: Use of TEMPORARY InnoDB tables with
    nullable columns could cause a server crash.

  * Security Fix: Using EXPLAIN with queries of the form
    could cause a server crash.

  * 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

       + 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

       + 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

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

    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.

  * Incompatible Change: Several changes were made to Performance
    Schema tables:

       + The SETUP_OBJECTS table was removed.

       + The PROCESSLIST table was renamed to THREADS.

       + The EVENTS_WAITS_SUMMARY_BY_EVENT_NAME table was renamed


  * Incompatible Change: Handling of warnings and errors
    during stored program execution was problematic:

       + If one statement generated several warnings or
         errors, only the handler for the first was
         activated, even if another might be more

       + Warning or error information could be lost.


  * Important Change: Replication: The LOAD DATA INFILE
    statement is now considered unsafe for statement-based
    replication. When using statement-based logging mode, the
    statement now produces a warning; when using mixed-format
    logging, the statement is made using the row-based

  * Partitioning: With innodb_thread_concurrency = 1, ALTER TABLE
    ... REORGANIZE PARTITION and SELECT could deadlock. There were
    unreleased latches in the ALTER TABLE ... REORGANIZE PARTITION
    thread which were needed by the SELECT thread to be able to
    continue. (Bug#54747:

  * Partitioning: An ALTER TABLE ... ADD PARTITION statement
    run concurrently with a read lock caused spurious
    ER_TABLE_EXISTS and ER_NO_SUCH_TABLE errors on subsequent
    See also

  * Partitioning: UPDATE and INSERT statements affecting
    partitioned tables performed poorly when using row-based

  * Partitioning: INSERT ON DUPLICATE KEY UPDATE statements
    performed poorly on tables having many partitions. This
    was because the handler function for reading a row from a
    specific index was not optimized in the partitioning

  * Partitioning: ALTER TABLE ... TRUNCATE PARTITION, when
    called concurrently with transactional DML on the table,
    was executed immediately and did not wait for the
    concurrent transaction to release locks. As a result, the
    ALTER TABLE statement was written into the binary log
    before the DML statement, which led to replication
    failures when using row-based logging.
    See also

  * Partitioning: When the storage engine used to create a
    partitioned table was disabled, attempting to drop the
    table caused the server to crash.

  * Replication: When using the row-based logging format, a
    failed CREATE TABLE ... SELECT statement was written to
    the binary log, causing replication to break if the
    failed statement was later re-run on the master. In such
    cases, a DROP TABLE ... IF EXIST statement is now logged
    in the event that a CREATE TABLE ... SELECT fails.

  * Replication: When using the row-based logging format, a
    SET PASSWORD statement was written to the binary log

  * Replication: When closing temporary tables, after the
    session connection was already closed, if the writing of
    the implicit DROP TABLE statement into the binary log
    failed, it was possible for the resulting error to be
    mishandled, triggering an assertion.

  * Replication: Executing SHOW BINLOG EVENTS increased the
    value of max_allowed_packet applying to the session that
    executed the statement.

  * Replication: Setting binlog_format = ROW then creating
    and then dropping a temporary table led an assertion.

  * Replication: When using mixed-format replication, changes
    made to a non-transactional temporary table within a
    transaction were not written into the binary log when the
    transaction was rolled back. This could lead to a failure
    in replication if the temporary table was used again
    See also

  * Replication: If binlog_format was explicitly switched
    from STATEMENT to ROW following the creation of a
    temporary table, then on disconnection the master failed
    to write the expected DROP TEMPORARY TABLE statement into
    the binary log. As a consequence, temporary tables (and
    their corresponding files) accumulated as this scenario
    was repeated.
    See also

  * Replication: If the SQL thread was started while the I/O
    thread was performing rotation of the relay log, the 2
    threads could begin to race for the same I/O cache,
    leading to a crash of the server.
    See also

  * Replication: Two related issues involving temporary
    tables and transactions were introduced by a fix made in
    MySQL 5.1.37:

      1. When a temporary table was created or dropped within
         a transaction, any failed statement that following
         statement triggered a rollback, which caused the
         slave diverge from the master.

         statement was executed within a transaction in which
         only tables using transactional storage engines were
         used and the transaction was rolled back at the end,
         the changes---including the creation of the
         temporary table---were not written to the binary

    The current fix restores the correct behavior in both of
    these cases.
    This regression was introduced by

  * Replication: The value of
    binlog_direct_non_transactional_updates had no effect on
    statements mixing transactional tables and
    nontransactional tables, or mixing temporary tables and
    nontransactional tables.
    As part of the fix for this issue, updates to temporary
    tables are now handled as transactional or
    nontransactional according to their storage engine types.
    (In effect, the current fix reverts a change made
    previously as part of the fix for
    In addition, unsafe mixed statements (that is, statements
    which access transactional table as well nontransactional
    or temporary tables, and write to any of them) are now
    handled as transactional when the statement-based logging
    format is in use.
    See also

  * Replication: When binlog_format=STATEMENT, any statement
    that is flagged as being unsafe, possibly causing the
    slave to go out of sync, generates a warning. This
    warning is written to the server log, the warning count
    is returned to the client in the server's response, and
    the warnings are accessible through SHOW WARNINGS.
    The current bug affects only the counts for warnings to
    the client and that are visible through SHOW WARNINGS; it
    does not affect which warnings are written to the log.
    The current issue came about because the fix for an
    earlier issue caused warnings for substatements to be
    cleared whenever a new substatement was started. However,
    this suppressed warnings for unsafe statements in some
    cases. Now, such warnings are no longer cleared.
    This regression was introduced by

  * Replication: Replication could break if a transaction
    involving both transactional and nontransactional tables
    was rolled back to a savepoint. It broke if a concurrent
    connection tried to drop a transactional table which was
    locked after the savepoint was set. This DROP TABLE
    completed when ROLLBACK TO SAVEPOINT was executed because
    the lock on the table was dropped by the transaction.
    When the slave later tried to apply the binary log
    events, it would fail because the table had already been

  * Replication: When CURRENT_USER() or CURRENT_USER was used
    to supply the name and host of the affected user or of
    the definer in any of the statements DROP USER, RENAME
    USER, GRANT, REVOKE, and ALTER EVENT, the reference to
    CURRENT_USER() or CURRENT_USER was not expanded when
    written to the binary log. This resulted in
    CURRENT_USER() or CURRENT_USER being expanded to the user
    and host of the slave SQL thread on the slave, thus
    breaking replication. Now CURRENT_USER() and CURRENT_USER
    are expanded prior to being written to the binary log in
    such cases, so that the correct user and host are
    referenced on both the master and the slave.

  * After an RPM installation mysqld would be started with the
    root, rather than the mysql user.

  * An assertion was raised if (1) an InnoDB table was created
    using CREATE TABLE ... SELECT where the query used an
    INFORMATION_SCHEMA table and a view existed in the database;
    or (2) sny statement that modified an InnoDB table had a
    subquery referencing an INFORMATION_SCHEMA table.

  * CMake would produce bad dependencies for the
    sql/lex_hash.h file during configuration.

  * mysql_upgrade did not handle the --ssl option properly.

  * Using MIN() or MAX() on a column containing the maximum
    TIME value caused a server crash.

  * Incorrect handling of user variable assignments as
    subexpressions could lead to incorrect results or server

  * The default compiler options used for Mac OS X 10.5 would
    be set incorrectly.

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

  * ORDER BY clauses that included user variable expressions
    could cause a debug assertion to be raised.

  * The InnoDB storage engine was not included in the default
    installation when using the configure script.

  * SHOW CREATE TRIGGER took a stronger metadata lock than
    required. This caused the statement to be blocked
    unnecessarily. For example, LOCK TABLES ... WRITE in one
    session blocked SHOW CREATE TRIGGER in another session.
    Also, a SHOW CREATE TRIGGER statement issued inside a
    transaction did not release its metadata locks at the end
    of statement execution. Consequently, SHOW CREATE TRIGGER
    was able to block other sessions from accessing the table
    (for example, using ALTER TABLE).

  * A single-table DELETE ordered by a column that had a
    hash-type index could raise an assertion or cause a
    server crash.

  * A call to mysql_library_init() following a call to
    mysql_library_end() caused a client crash.

  * A statement that was aborted by KILL QUERY while it
    waited on a metadata lock could raise an assertion in
    debug builds, or send OK to the client instead of
    ER_QUERY_INTERRUPTED in regular builds.

  * The mysql_config tool would not output the requirement
    for the aio library for mysqld-libs.

  * GROUP BY operations used max_sort_length inconsistently.

  * The Windows MSI installer would fail to preserve custom
    settings, such as the configured data directory, during

  * IF() with a subquery argument could raise a debug assertion
    for debug builds under some circumstances.

  * Building MySQL on Solaris 8 x86 failed when using Sun
    Studio due to gcc inline assembler code.

  * When upgrading an existing install with an RPM on Linux,
    the MySQL server might not have been restarted properly.
    This was due to a naming conflict when upgrading from a
    community named RPM. Previous installations are now
    correctly removed, and the MySQL init script are
    recreated and then start the MySQL server as normal.

  * The thread_concurrency system variable was unavailable on
    non-Solaris systems.

  * mysqld_safe contained a syntax error that prevented it
    from restarting the server.

  * If audit plugins were installed that were interested in
    MYSQL_AUDIT_GENERAL_CLASS events and the general query
    log was disabled, failed INSTALL PLUGIN or UNINSTALL
    PLUGIN statements caused a server crash.

  * A SHOW CREATE TABLE statement issued inside a transaction
    did not release its metadata locks at the end of
    statement execution. Consequently, SHOW CREATE TABLE was
    able to block other sessions from accessing the table
    (for example, using ALTER TABLE).

    MyISAM as the default storage engine, but this is not
    true as of MySQL 5.5.5.

  * The MERGE storage engine tried to use memory mapping on
    the underlying MyISAM tables even on platforms that do
    not support it and even when myisam_use_mmap was
    disabled. This led to a hang for INSERT INTO ... SELECT
    FROM statements that selected from a MyISAM table into a
    MERGE table that contained the same MyISAM table.

  * Incorrect error handling could result in an OPTIMIZE
    TABLE crash.

  * Performance Schema event collection for a thread could
    "leak" from one connection to another if the thread was
    used for one connection, then cached, then reused for
    another connection.

  * Some memory used for InnoDB asynchronous I/O was not freed at
    shutdown. (Bug#54764:

  * In debug builds, an assertion could be raised when the
    server tried to send an OK packet to the client after
    having failed to detect errors during processing of the
    WHERE condition of an UPDATE statement.

  * In a slave SQL thread or Event Scheduler thread, the
    SLEEP() function could not sleep more than five seconds.

  * Implementation of the 64-bit dulint structure in InnoDB
    was not optimized for 64-bit processors, resulting in
    excessive storage and reduced performance.

  * The output from the SHOW ENGINE INNODB STATUS command now
    includes information about "spin rounds" for RW-locks
    (both shared and exclusive locks).

  * SET sql_select_limit = 0 did not work.

  * An ALTER TABLE statement could convert an InnoDB
    compressed table (with row_format=compressed) back to an
    uncompressed table (with row_format=compact).

  * Assignments of the PASSWORD() or OLD_PASSWORD() function
    to a user variable did not preserve the character set of
    the function return value.

  * A signal-handler redefinition for SIGUSR1 was removed.
    The redefinition could cause the server to encounter a
    kernel deadlock on Solaris when there are many active
    threads. Other POSIX platforms might also be affected.

  * InnoDB could issue an incorrect message on startup, if
    tables were created under the setting
    innodb_file_per_table=ON and the server was restarted
    under the setting innodb_file_per_table=OFF. The message
    was of the form InnoDB: Warning: allocated tablespace n,
    old maximum was 0.

  * Queries that named view columns in a GROUP BY clause
    could cause a server crash.

  * Performance Schema displayed spurious startup error
    messages when the server was run in bootstrap mode.

  * For distributions built with cmake rather than the GNU
    autotools, mysql lacked pager support.

  * The server failed to disregard sort order for some
    zero-length tuples, leading to an assertion failure.

  * The default value of myisam_max_extra_sort_file_size
    iables.html#sysvar_myisam_max_extra_sort_file_size) could
    be higher than the maximum accepted value, leading to
    warnings upon the server start.

  * The database server could crash when renaming a table
    that had active transactions. (This issue only affected
    the database server when built for debugging.)

  * The server could crash during the recovery phase of
    startup, if it previously crashed while inserting BLOB or
    other large columns that use off-page storage into an
    InnoDB table created with ROW_FORMAT=REDUNDANT or

  * Errors during processing of WHERE conditions in HANDLER
    ... READ statements were not detected, so the handler
    code still tried to send EOF to the client, raising an

  * If a session tried to drop a database containing a table
    opened with HANDLER in another session, any DATABASE
    statement (CREATE, DROP, ALTER) executed by that session
    produced a deadlock.

  * For an InnoDB table created with ROW_FORMAT=COMPRESSED or
    isolation level could cause the server to stop with an
    assertion error, if BLOB or other large columns that use
    off-page storage were being inserted at the same time.

  * Fast index creation in the InnoDB Plugin could fail,
    leaving the new secondary index corrupted.

  * For distributions built with cmake rather than the GNU
    autotools, some scripts were built without the execute
    bit set.

  * INSERT IGNORE INTO ... SELECT statements could cause a
    debug assertion to be raised.

  * A client could supply data in chunks to a prepared
    statement parameter other than of type TEXT or BLOB using
    the mysql_stmt_send_long_data() C API function (or
    COM_STMT_SEND_LONG_DATA command). This led to a crash
    because other data types are not valid for long data.

  * mysql_secure_installation did not properly identify local
    accounts and could incorrectly remove nonlocal root

  * A client with automatic reconnection enabled saw the
    error message Lost connection to MySQL server during
    query if the connection was lost between the
    mysql_stmt_prepare() and mysql_stmt_execute() C API
    functions. However, mysql_stmt_errno() returned 0, not
    the corresponding error number 2013.

  * INFORMATION_SCHEMA.COLUMNS reported incorrect precision
    for BIGINT UNSIGNED columns.

  * If a session executing TRUNCATE TABLE on an InnoDB table
    was killed during open_tables(), an assertion could be

  * Transactions could be incorrectly committed during
    recovery, rather than rolled back, if the server crashed
    and was restarted after performing ALTER TABLE...ADD
    PRIMARY KEY on an InnoDB table, or some other operation
    that involves copying the entire table.

  * The patch for
    Bug#36569: caused
    performance regressions and incorrect execution of some
    UPDATE statments.

  * Missing Performance Schema tables were not reported in
    the error log at server startup.

  * mysql_upgrade could incorrectly remove TRIGGER

    amount of memory allocated by Performance Schema.

  * Portability problems in SHOW STATUS could lead to
    incorrect results on some platforms.

  * Builds of MySQL generated a large number of warnings.

  * Performance Schema header files were not installed in the
    correct directory.

  * The server could crash when processing subqueries with
    empty results.

  * Misimplementation of the os_fast_mutex_trylock() function
    in InnoDB resulted in unnecessary blocking and reduced

  * With lower_case_table_names set to a nonzero value,
    searches for table or database names in
    INFORMATION_SCHEMA tables could produce incorrect

  * Use of uint in typelib.h caused compilation problems in
    Windows. This was changed to unsigned int.

  * The mysql-debug.pdb supplied with releases did not match
    the corresponding mysqld.exe.

  * The PERFORMANCE_SCHEMA database was not correctly created and
    populated on Windows.

  * The large_pages system variable was tied to the
    --large-files command-line option, not the --large-pages

  * Attempts to access a nonexistent table in the
    performance_schema database resulted in a misleading
    error message.

  * The ABI check for MySQL failed to compile with gcc 4.5.

  * Performance Schema could enter an infinite loop if
    required to create a large number of mutex instances.

  * mysql_secure_installation sometimes failed to locate the
    mysql client.

  * InnoDB could not create tables that used the utf32
    character set.

  * Some queries involving GROUP BY and a function that
    returned DATE raised a debug assertion.

  * If a symbolic link was used in a file path name, the
    Performance Schema did not resolve all file io events to
    the same name.

  * PARTITION BY KEY on a utf32 ENUM column raised a
    debugging assertion.

  * A pending FLUSH TABLES tbl_list WITH READ LOCK statement
    unnecessarily aborted transactions.

  * FLUSH TABLES WITH READ LOCK in one session and FLUSH
    TABLES tbl_list WITH READ LOCK in another session were
    mutually exclusive.

  * Reading a ucs2 data file with LOAD DATA INFILE was
    subject to three problems. 1) Incorrect parsing of the
    file as ucs2 data, resulting in incorrect length of the
    parsed string. This is fixed by truncating the invalid
    trailing bytes (incomplete multibyte characters) when
    reading from the file. 2) Reads from a proper ucs2 file
    did not recognize newline characters. This is fixed by
    first checking whether a byte is a newline (or any other
    special character) before reading it as a part of a
    multibyte character. 3) When using user variables to hold
    column data, the character set of the user variable was
    set incorrectly to the database charset. This is fixed by
    setting it to the character set specified in the LOAD
    DATA INFILE statement, if any.

  * XA START had a race condition that could cause a server

  * The results of some ORDER BY ... DESC queries were sorted

  * Index Merge between three indexes could return incorrect

  * MIN() and MAX() returned incorrect results for DATE
    columns if the set of values included '0000-00-00'.

  * Searches in INFORMATION_SCHEMA tables for rows matching a
    nonexistent database produced an error instead of an
    empty query result.

  * DROP DATABASE failed if there was a TEMPORARY table with
    the same name as a non-TEMPORARY table in the database.

  * Performing large numbers of RENAME TABLE statements
    caused excessive memory use.

  * An assertion occurred in line 1137:
    The problem was found while running RQG tests and the
    assertion occurred during REPAIR, OPTIMIZE, and ANALYZE

  * The optimize method of the ARCHIVE storage engine did not
    preserve the FRM embedded in the ARZ file when rewriting
    the ARZ file for optimization. This meant an ARCHIVE
    table that had been optimized could not be discovered.
    The ARCHIVE engine stores the FRM in the ARZ file so it
    can be transferred from machine to machine without also
    needing to copy the FRM file. The engine subsequently
    restores the embedded FRM during discovery.

  * With character_set_connection set to utf16 or utf32,
    CREATE TABLE t1 AS SELECT HEX() ... caused a server

  * The my_like_range_xxx() functions returned badly formed
    maximum strings for Asian character sets, which caused
    problems for storage engines.

  * A debugging assertion could be raised after a write
    failure to a closed socket.

  * Enumeration plugin variables were subject to a type
    casting error, causing inconsistent results between
    different platforms.

  * Sort-index_merge for join tables other than the first
    table used excessive memory.

  * The mechanism that checks if there is enough space for
    redo logs was improved, reducing the chance of
    encountering this message: ERROR: the age of the last
    checkpoint is x, which exceeds the log group capacity y.

  * Rows inserted in a table by one session were not
    immediately visible to another session that queried the
    table, even if the insert had committed.

  * Statements of the form UPDATE ... WHERE ... ORDER BY used
    a filesort even when not required.
    See also

  * Reading from a temporary MERGE table, with two
    non-temporary child MyISAM tables, resulted in the error:
        ERROR 1168 (HY000): Unable to open underlying table which is
        differently defined or of non-MyISAM type or doesn't exist

  * safemalloc was excessively slow under certain conditions
    and has been removed. The --skip-safemalloc server option
    has also been removed, and the --with-debug=full
    configuration option is no different from --with-debug.

  * Threads that were calculating the estimated number of
    records for a range scan did not respond to the KILL
    statement. That is, if a range join type is possible
    (even if not selected by the optimizer as a join type of
    choice and thus not shown by EXPLAIN), the query in the
    statistics state (shown by the SHOW PROCESSLIST) did not
    respond to the KILL statement.

  * Problems in the atomic operations implementation could
    lead to server crashes.

  * Improved performance and scalability on Windows systems,
    especially for Windows Vista and higher. Re-enabled the
    use of atomic instructions on Windows systems. For
    Windows Vista and higher, reduced the number of event
    handles used. To compile on Windows systems now requires
    Windows SDK v6.0 or later; either upgrade to Visual
    Studio 2008 or 2010, or for Visual Studio 2005, install
    Windows SDK Update for Windows Vista.


On behalf of the MySQL Build Team,
Jörg Brühe

Joerg Bruehe,  MySQL Build Team,  joerg.bruehe@stripped
ORACLE Deutschland B.V. & Co. KG,   Komturstrasse 18a,   D-12099 Berlin
Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven
Amtsgericht Muenchen: HRA 95603

MySQL Community Server 5.5.6-rc has been releasedJoerg Bruehe19 Sep