MySQL Forums
Forum List  »  Announcements

MySQL Community Server 5.5.7-rc has been released
Posted by: hery ramilison
Date: November 10, 2010 01:16PM


Dear MySQL users,


MySQL Server 5.5.7-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.

For commercial offerings, see

    http://mysql.com/products/

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

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

    http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html

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.7-rc on new servers, please see
the MySQL installation documentation at

    http://dev.mysql.com/doc/refman/5.5/en/installing.html

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

http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html

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

    http://dev.mysql.com/downloads/mysql/

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

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

    http://dev.mysql.com/doc/refman/5.5/en/news-5-5-7.html

Special note for those of you who build from source:

Since MySQL 5.5.5-m3, CMake has been used as the build framework for all platforms. See how you can use CMake as per the instructions on this web page:

   http://forge.mysql.com/wiki/CMake

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

----

Changes in MySQL 5.5.7-rc:

Authentication Changes:

  * MySQL authentication supports two new capabilities, pluggable
    authentication and proxy users:

       + With pluggable authentication, the server can use plugins
         to authenticate incoming client connections, and clients
         can load an authentication plugin that interacts properly
         with the corresponding server plugin. This capability
         enables clients to connect to the MySQL server with
         credentials that are appropriate for authentication
         methods other than the built-in MySQL authentication
         based on native MySQL passwords stored in the mysql.user
         table. For example, plugins can be created to use
         external authentication methods such as LDAP, Kerberos,
         PAM, or Windows login IDs.

       + Proxy user capability enables a client who connects and
         authenticates as one user to be treated, for purposes of
         access control while connected, as having the privileges
         of a different user. In effect, one user impersonates
         another. Proxy capability depends on pluggable
         authentication because it is based on having an
         authentication plugin return to the server the user name
         that the connecting user impersonates.

    Pluggable authentication entails these changes:

       + For user specifications in the CREATE USER and GRANT
         statements, a new IDENTIFIED WITH clause for specifying
         the authentication plugin.

       + For the mysql.user table, new columns that specify plugin
         information. The plugin column, if nonempty, indicates
         which plugin authenticates connections for an account.
         The authentication_string column is a string that is
         passed to the plugin.

       + For the mysql_options() C API function, new
         MYSQL_DEFAULT_AUTH and MYSQL_PLUGIN_DIR options that
         enable client programs to load authentication plugins.

       + For the mysql client, new --default-auth and --plugin-dir
         options for specifying which authentication plugin and
         plugin directory to use.

       + For the mysqltest client, a new --plugin-dir option for
         specifying which plugin directory to use, and a new
         connect() command argument to specify an authentication
         plugin.

       + For the server plugin API, a new
         MYSQL_AUTHENTICATION_PLUGIN plugin type.

       + A client plugin API that enables client programs to
         manage plugins.

       + Reimplementation of the built-in authentication methods
         previously supported in MySQL as plugins. These methods
         provide native password checking and pre-MySQL 4.1.1
         authentication that uses shorter password hash values.
         This change only reimplements the built-in methods as
         plugins that cannot be unloaded. Existing clients
         authenticate as before with no changes needed. In
         particular, starting the server with the --secure-auth
         option still prevents clients that have pre-4.1.1
         password hashes from connecting, and --skip-grant-tables
         still disables all password checking.

    Proxy user capability entails these changes:

       + A new PROXY privilege that can be managed with the GRANT
         and REVOKE statements.

       + New proxy_user and external_user system variables that
         indicate whether the current session uses proxying.

       + A new mysql.proxies_priv grant table that records proxy
         information for MySQL accounts.
    Due to these changes, the server requires that the new grant
    table, proxies_priv, be present in the mysql database. If you
    are upgrading from a previous MySQL release rather than
    performing a new installation, the server will exit during
    startup after finding that this table is missing. To create
    the table, start the server with the --skip-grant-tables
    option to cause it to skip the normal grant table checks, then
    run mysql_upgrade. For example:
      shell> mysqld --skip-grant-tables &
      shell> mysql_upgrade
    Then stop the server and restart it normally.
    You can specify other options on the mysqld command line if
    necessary. Alternatively, if your installation is configured
    so that the server normally reads options from an option file,
    use the --defaults-file option to specify the file (enter each
    command on a single line):
      shell> mysqld --defaults-file=/usr/local/mysql/etc/my.cnf
             --skip-grant-tables &
      shell> mysql_upgrade
    With the --skip-grant-tables option, the server does no
    password or privilege checking, so any client can connect and
    effectively have all privileges. For additional security, use
    the --skip-networking option as well to prevent remote clients
    from connecting.
    For additional information, consult these references:

       + Information about pluggable authentication, including
         installation and usage instructions: Section 5.5.6,
         "Pluggable Authentication."

       + Information about proxy users: Section 5.5.7, "Proxy
         Users."

       + Information about the server and client plugin API:
         Section 23.2.4.1, "General Plugin Data Structures and
         Functions."

       + Information about the C API functions for managing client
         plugins: See Section 22.9.10, "Client Plugin API C
         Functions."

Functionality added or changed:

  * The unused and undocumented thread_pool_size system variable
    was removed.
    (Bug#57338: http://bugs.mysql.com/bug.php?id=57338)

  * A new status variable, Handler_read_last, displays the number
    of requests to read the last key in an index. With ORDER BY,
    the server will issue a first-key request followed by several
    next-key requests, whereas with With ORDER BY DESC, the server
    will issue a last-key request followed by several previous-key
    requests. (Bug#52312: http://bugs.mysql.com/bug.php?id=52312)

Bugs fixed:

  * Performance: InnoDB Storage Engine: The master InnoDB
    background thread could sometimes cause transient performance
    drops due to excessive flushing of modified pages.
    (Bug#56933: http://bugs.mysql.com/bug.php?id=56933)

  * Security Fix: The server crashed for assignment of values of
    types other than Geometry to items of type GeometryCollection
    (MultiPoint, MultiCurve, MultiSurface). Now the server checks
    the field type and fails with bad geometry value if it detects
    incorrect parameters.
    (Bug#55531: http://bugs.mysql.com/bug.php?id=55531)

  * Security Fix: EXPLAIN EXTENDED caused a server crash with some
    prepared statements.
    (Bug#54494: http://bugs.mysql.com/bug.php?id=54494)

  * Security Fix: In prepared-statement mode, EXPLAIN for a SELECT
    from a derived table caused a server crash.
    (Bug#54488: http://bugs.mysql.com/bug.php?id=54488)

  * Security Fix: The PolyFromWKB() function could crash the
    server when improper WKB data was passed to the function.
    (Bug#51875: http://bugs.mysql.com/bug.php?id=51875,
    CVE-2010-3840
    (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3840))

  * Incompatible Change: Replication: The behavior of INSERT
    DELAYED statements when using statement-based replication has
    changed as follows:
    Previously, when using binlog_format=STATEMENT, a warning was
    issued in the client when executing INSERT DELAYED; now, no
    warning is issued in such cases.
    Previously, when using binlog_format=STATEMENT, INSERT DELAYED
    was logged as INSERT DELAYED; now, it is logged as an INSERT,
    without the DELAYED option.
    However, when binlog_format=STATEMENT, INSERT DELAYED
    continues to be executed as INSERT (without the DELAYED
    option). The behavior of INSERT DELAYED remains unchanged when
    using binlog_format=ROW: INSERT DELAYED generates no warnings,
    is executed as INSERT DELAYED, and is logged using the
    row-based format.
    This change also affects binlog_format=MIXED, because INSERT
    DELAYED is no longer considered unsafe. Now, when the logging
    format is MIXED, no switch to row-based logging occurs. This
    means that the statement is logged as a simple INSERT (that
    is, without the DELAYED option), using the statement-based
    logging format.
    (Bug#54579: http://bugs.mysql.com/bug.php?id=54579)

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

  * InnoDB Storage Engine: Replication: If the master had
    innodb_file_per_table=OFF, innodb_file_format=Antelope (and
    innodb_strict_mode=OFF), or both, certain CREATE TABLE
    options, such as KEY_BLOCK_SIZE, were ignored. This could
    allow master to avoid raising ER_TOO_BIG_ROWSIZE errors.
    However, the ignored CREATE TABLE options were still written
    into the binary log, so that, if the slave had
    innodb_file_per_table=ON and innodb_file_format=Barracuda, it
    could encounter an ER_TOO_BIG_ROWSIZE error while executing
    the record from the log, causing the slave SQL thread to abort
    and replication to fail.
    In the case where the master was running MySQL 5.1 and the
    slave was MySQL 5.5 (or later), the failure occurred when both
    master and slave were running with default values for
    innodb_file_per_table and innodb_file_format. This could cause
    problems during upgrades.
    To address this issue, the default values for
    innodb_file_per_table and innodb_file_format are reverted to
    the MySQL 5.1 default values---that is, OFF and Antelope,
    respectively.
    (Bug#56318: http://bugs.mysql.com/bug.php?id=56318)

  * InnoDB Storage Engine: The server could crash with a high
    volume of concurrent LOCK TABLE and UNLOCK TABLES statements.
    (Bug#57345: http://bugs.mysql.com/bug.php?id=57345)

  * InnoDB Storage Engine: InnoDB incorrectly reported an error
    when a cascading foreign key constraint deleted more than 250
    rows. (Bug#57255: http://bugs.mysql.com/bug.php?id=57255)

  * InnoDB Storage Engine: The output from the SHOW ENGINE INNODB
    STATUS command can now be up to 1 MB. Formerly, it was
    truncated at 64 KB. Monitoring applications that parse can
    check if output exceeds this new, larger limit by testing the
    Innodb_truncated_status_writes status variable.
    (Bug#56922: http://bugs.mysql.com/bug.php?id=56922)

  * InnoDB Storage Engine: A SELECT ... FOR UPDATE statement
    affecting a range of rows in an InnoDB table could cause a
    crash in the debug version of the server.
    (Bug#56716: http://bugs.mysql.com/bug.php?id=56716)

  * InnoDB Storage Engine: Improved the performance of UPDATE
    operations on InnoDB tables, when only non-indexed columns are
    changed. (Bug#56340: http://bugs.mysql.com/bug.php?id=56340)

  * InnoDB Storage Engine: When MySQL was restarted after a crash
    with the option innodb_force_recovery=6, certain queries
    against InnoDB tables could fail, depending on WHERE or ORDER
    BY clauses.
    Usually in such a disaster recovery situation, you dump the
    entire table using a query without these clauses. During
    advanced troubleshooting, you might use queries with these
    clauses to diagnose the position of the corrupted data, or to
    recover data following the corrupted part.
    (Bug#55832: http://bugs.mysql.com/bug.php?id=55832)

  * InnoDB Storage Engine: 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)

  * InnoDB Storage Engine: A heavy workload with a large number of
    threads could cause a crash in the debug version of the
    server. (Bug#55699: http://bugs.mysql.com/bug.php?id=55699)

  * InnoDB Storage Engine: The server could crash on shutdown, if
    started with --innodb-use-system-malloc=0.
    (Bug#55627: http://bugs.mysql.com/bug.php?id=55627)

  * InnoDB Storage Engine: If the server crashed during a RENAME
    TABLE operation on an InnoDB table, subsequent crash recovery
    could fail. This problem could also affect an ALTER TABLE
    statement that caused a rename operation internally.
    (Bug#55027: http://bugs.mysql.com/bug.php?id=55027)

  * InnoDB Storage Engine: Setting the PACK_KEYS=0 table option
    for an InnoDB table prevented new indexes from being added to
    the table. (Bug#54606: http://bugs.mysql.com/bug.php?id=54606)

  * InnoDB Storage Engine: Changed the locking mechanism for the
    InnoDB data dictionary during ROLLBACK operations, to improve
    concurrency for REPLACE statements.
    (Bug#54538: http://bugs.mysql.com/bug.php?id=54538)

  * InnoDB Storage Engine: With multiple buffer pools enabled,
    InnoDB could flush more data from the buffer pool than
    necessary, causing extra I/O overhead.
    (Bug#54346: http://bugs.mysql.com/bug.php?id=54346)

  * InnoDB Storage Engine: InnoDB 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.
    (Bug#53756: http://bugs.mysql.com/bug.php?id=53756)

  * InnoDB Storage Engine: InnoDB startup messages now include the
    start and end times for buffer pool initialization, and the
    total buffer pool size.
    (Bug#48026: http://bugs.mysql.com/bug.php?id=48026)

  * Partitioning: Multi-table UPDATE statements involving a
    partitioned MyISAM table could cause this table to become
    corrupted. Not all tables affected by the UPDATE needed to be
    partitioned for this issue to be observed.
    (Bug#55458: http://bugs.mysql.com/bug.php?id=55458)

  * Partitioning: EXPLAIN PARTITIONS returned bad estimates for
    range queries on partitioned MyISAM tables. In addition,
    values in the rows column of EXPLAIN PARTITIONS output did not
    take partition pruning into account.
    (Bug#53806: http://bugs.mysql.com/bug.php?id=53806,
    Bug#46754: http://bugs.mysql.com/bug.php?id=46754)

  * Replication: SET PASSWORD caused row-based replication to fail
    between a MySQL 5.1 master and a MySQL 5.5 slave.
    This fix makes it possible to replicate SET PASSWORD
    correctly, using row-based replication between a master
    running MySQL 5.1.53 or a later MySQL 5.1 release to a slave
    running MySQL 5.5.7 or a later MySQL 5.5 release.
    (Bug#57098: http://bugs.mysql.com/bug.php?id=57098)
    See also Bug#55452: http://bugs.mysql.com/bug.php?id=55452,
    Bug#57357: http://bugs.mysql.com/bug.php?id=57357.

  * Replication: Backticks used to enclose identifiers for
    savepoints were not preserved in the binary log, which could
    lead to replication failure when the identifier, stripped of
    backticks, could be misinterpreted, causing a syntax or other
    error.
    This could cause problems with MySQL application programs
    making use of generated savepoint IDs. If, for instance,
    java.sql.Connection.setSavepoint() is called without any
    parameters, Connector/J automatically generates a savepoint
    identifier consisting of a string of hexadecimal digits 0-F
    encased in backtick (`) characters. If such an ID took the
    form `NeN` (where N represents a string of the decimal digits
    0-9, and e is a literal uppercase or lowercase "E" character).
    Removing the backticks when writing the identifier into the
    binary log left behind a substring which the slave MySQL
    server tried to interpret as a floating point number, rather
    than as an identifier. The resulting syntax error caused loss
    of replication.
    (Bug#55961: http://bugs.mysql.com/bug.php?id=55961)
    See also Bug#55962: http://bugs.mysql.com/bug.php?id=55962.

  * Replication: When a slave tried to execute a transaction
    larger than the slave's value for max_binlog_cache_size, it
    crashed. This was caused by an assertion that the server
    should roll back only the statement but not the entire
    transaction when the error ER_TRANS_CACHE_FULL occurred.
    However, the slave SQL thread always rolled back the entire
    transaction whenever any error occurred, regardless of the
    type of error.
    (Bug#55375: http://bugs.mysql.com/bug.php?id=55375)

  * Replication: The error message for
    ER_SLAVE_HEARTBEAT_VALUE_OUT_OF_RANGE was hard coded in
    English in sql_yacc.yy, so that it could not be translated in
    errmsg.txt for other languages.
    Additionally, this same error message was used for three
    separate error conditions:

      1. When the heartbeat period exceeded the value of
         slave_net_timeout.

      2. When the heartbeat period was nonnegative but shorter
         than 1 millisecond.

      3. When the value for the heartbeat period was either
         negative or greater than the maximum allowed.
    These issues have been addressed as follows:

       + By using three distinct error messages for each of the
         conditions listed previously.

       + By moving the sources for these error messages into the
         errmsg-utf8.txt file to facilitate translations into
         languages other than English.
    (Bug#54144: http://bugs.mysql.com/bug.php?id=54144)

  * A buffer overrun could occur when formatting DBL_MAX numbers.
    (Bug#57209: http://bugs.mysql.com/bug.php?id=57209)

  * The server could crash inside memcpy() when reading certain
    Performance Schema tables.
    (Bug#56761: http://bugs.mysql.com/bug.php?id=56761)

  * Memory leaks detected by Valgrind were corrected.
    (Bug#56709: http://bugs.mysql.com/bug.php?id=56709)

  * It was possible to compile mysqld with Performance Schema
    support but with a dummy atomic-operations implementation,
    which caused a server crash. This problem does not affect
    binary distributions. It is helpful as a safety measure for
    users who build MySQL from source.
    (Bug#56521: http://bugs.mysql.com/bug.php?id=56521)

  * The server crashed if a table maintenance statement such as
    ANALYZE TABLE or REPAIR TABLE was executed on a MERGE table
    and opening and locking a child table failed. For example,
    this could happen if a child table did not exist or if a lock
    timeout happened while waiting for a conflicting metadata lock
    to disappear.
    As a consequence of this bug fix, it is now possible to use
    CHECK TABLE for log tables without producing an error.
    (Bug#56422: http://bugs.mysql.com/bug.php?id=56422,
    Bug#56494: http://bugs.mysql.com/bug.php?id=56494)

  * Deadlock could occur for heavily concurrent workloads
    consisting of a mix of DML, DDL, and FLUSH TABLES statements
    affecting the same set of tables.
    (Bug#56405: http://bugs.mysql.com/bug.php?id=56405)

  * The server could crash during shutdown due to a race condition
    relating to Performance Schema cleanup.
    (Bug#56324: http://bugs.mysql.com/bug.php?id=56324)

  * ALTER TABLE on a MERGE table could result in deadlock with
    other connections.
    (Bug#56292: http://bugs.mysql.com/bug.php?id=56292,
    Bug#57002: http://bugs.mysql.com/bug.php?id=57002)

  * The tcmalloc library was missing from binary MySQL packages
    for Linux. (Bug#56267: http://bugs.mysql.com/bug.php?id=56267)

  * An INSERT DELAYED statement for a MERGE table could cause
    deadlock if it occurred as part of a transaction or under LOCK
    TABLES, and there was a concurrent DDL or LOCK TABLES ...
    WRITE statement that tried to lock one of its underlying
    tables. (Bug#56251: http://bugs.mysql.com/bug.php?id=56251)

  * In debug builds, the server raised an assertion for DROP
    DATABASE in installations that had an outdated or corrupted
    mysql.proc table. For example, this affected mysql_upgrade
    when run as part of a MySQL 5.1 to 5.5 upgrade.
    (Bug#56137: http://bugs.mysql.com/bug.php?id=56137)

  * A negative TIME argument to MIN() or MAX() could raise an
    assertion. (Bug#56120: http://bugs.mysql.com/bug.php?id=56120)

  * The ordering for supplementary characters with the
    utf8mb4_bin, utf16_bin, and utf32_bin collations was
    incorrect. (Bug#55980: http://bugs.mysql.com/bug.php?id=55980)

  * Short (single-letter) command-line options did not work.
    (Bug#55873: http://bugs.mysql.com/bug.php?id=55873)

  * If a query specified a DATE or DATETIME value in a format
    different from 'YYYY-MM-DD HH:MM:SS', a greater-than-or-equal
    (>=) condition matched only greater-than values in an indexed
    TIMESTAMP column.
    (Bug#55779: http://bugs.mysql.com/bug.php?id=55779)

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

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

  * For Performance Schema, the default number of rwlock classes
    was increased to 30, and the default number of rwlock and
    mutex instances was increased to 1 million. These changes were
    made to account for the volume of data instrumented when the
    InnoDB storage engine is used (because of the InnoDB buffer
    pool). (Bug#55576: http://bugs.mysql.com/bug.php?id=55576)

  * If there was an active SELECT statement, an error arising
    during trigger execution could cause a server crash.
    (Bug#55421: http://bugs.mysql.com/bug.php?id=55421)

  * Assignment of InnoDB scalar subquery results to a variable
    resulted in unexpected S locks in READ COMMITTED transaction
    isolation level.
    (Bug#55382: http://bugs.mysql.com/bug.php?id=55382)

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

  * With an UPDATE IGNORE statement including a subquery that was
    evaluated using a temporary table, an error transferring the
    data from the temporary was ignored, causing an assertion to
    be raised. (Bug#54543: http://bugs.mysql.com/bug.php?id=54543)

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

  * If one session attempted to drop a database containing a table
    which another session had opened with HANDLER, any instance of
    ALTER DATABASE, CREATE DATABASE, or DROP DATABASE issued by
    the latter session produced a deadlock.
    (Bug#54360: http://bugs.mysql.com/bug.php?id=54360)

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

  * Row subqueries producing no rows were not handled as UNKNOWN
    values in row comparison expressions.
    (Bug#54190: http://bugs.mysql.com/bug.php?id=54190)

  * Setting SETUP_INSTRUMENTS.TIMER = 'NO' caused TIMER_WAIT
    values for aggregations to be NULL rather than 0.
    (Bug#53874: http://bugs.mysql.com/bug.php?id=53874)

  * The max_length metadata value of MEDIUMBLOB types was reported
    as 1 byte greater than the correct value.
    (Bug#53296: http://bugs.mysql.com/bug.php?id=53296)

  * If an application using the embedded server called
    mysql_library_init() a second time after calling
    mysql_library_init() and mysql_library_end() to start and stop
    the server, the application crashed when reading option files.
    (Bug#53251: http://bugs.mysql.com/bug.php?id=53251)

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

  * The plugin_ftparser.h and plugin_audit.h include files are
    part of the public API/ABI, but were not tested by the ABI
    check. (Bug#52821: http://bugs.mysql.com/bug.php?id=52821)

  * An atomic "compare and swap" operation using x86 assembly code
    (32 bit) could access incorrect data, which would make it work
    incorrectly and lose the intended atomicity. This would in
    turn cause the MySQL server to work on inconsistent data
    structures and return incorrect data. That code part affected
    only 32-bit builds; the effect has been observed when icc was
    used to build binaries. With gcc, no incorrect results have
    been observed during tests, so this fix is a proactive one.
    Other compilers do not use this assembly code.
    (Bug#52419: http://bugs.mysql.com/bug.php?id=52419)

  * In LOAD DATA INFILE, using a SET clause to set a column equal
    to itself caused a server crash.
    (Bug#51850: http://bugs.mysql.com/bug.php?id=51850)

  * In some cases, when the left part of a NOT IN subquery
    predicate was a row and contained NULL values, the query
    result was incorrect.
    (Bug#51070: http://bugs.mysql.com/bug.php?id=51070)

  * CHECKSUM TABLE for Performance Schema tables could cause a
    server crash due to uninitialized memory reads.
    (Bug#50557: http://bugs.mysql.com/bug.php?id=50557)

  * For some queries, the optimizer produced incorrect results
    using the Index Merge access method with InnoDB tables.
    (Bug#50402: http://bugs.mysql.com/bug.php?id=50402)

  * EXPLAIN produced an incorrect rows value for queries evaluated
    using an index scan and that included LIMIT, GROUP BY, and
    ORDER BY on a computed column.
    (Bug#50394: http://bugs.mysql.com/bug.php?id=50394)

  * mysql_store_result() and mysql_use_result() are not for use
    with prepared statements and are not intended to be called
    following mysql_stmt_execute(), but failed to return an error
    when invoked that way.
    (Bug#47485: http://bugs.mysql.com/bug.php?id=47485)

  * Using REPAIR TABLE table USE_FRM on a MERGE table caused the
    server to crash.
    (Bug#46339: http://bugs.mysql.com/bug.php?id=46339)

  * If the global and session debug system variables had the same
    value, the debug trace file could be closed twice, leading to
    freeing already freed memory and a server crash.
    (Bug#46165: http://bugs.mysql.com/bug.php?id=46165)

  * Trailing space removal for utf32 strings was done with
    non-multibyte-safe code, leading to incorrect result length
    and assertion failure.
    (Bug#42511: http://bugs.mysql.com/bug.php?id=42511)

  * A malformed packet sent by the server when the query cache was
    in use resulted in lost-connection errors.
    (Bug#42503: http://bugs.mysql.com/bug.php?id=42503)

  * Multiple-statement execution could fail.
    (Bug#40877: http://bugs.mysql.com/bug.php?id=40877)

  * CREATE TABLE failed if a column referred to in an index
    definition and foreign key definition was in different
    lettercases in the two definitions.
    (Bug#39932: http://bugs.mysql.com/bug.php?id=39932)


Enjoy!

On behalf of the MySQL Build Team,
Hery Ramilison


Options: ReplyQuote


Subject
Views
Written By
Posted
MySQL Community Server 5.5.7-rc has been released
7798
November 10, 2010 01:16PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.