List:Packagers« Previous MessageNext Message »
From:Hery Ramilison Date:February 8 2011 5:12am
Subject:MySQL Community Server 5.5.9 has been released
View as plain text  
Dear MySQL users,

MySQL 5.5.9 is a new version of the 5.5 production version of the
world's most popular open source database. MySQL 5.5.9 is recommended
for use on production systems.

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.  MySQL 5.5 also provides a number of other new enhancements,
including:

   - InnoDB I/O Subsystem Changes
   - Enhanced Solaris Support
   - Diagnostic and Monitoring Capabilities

For a more complete look at what's new in MySQL 5.5, please see

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

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

   http://mysql.com/products/enterprise/

For information on installing MySQL 5.5.9 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.html

MySQL Server 5.5 is available in source and binary form for a number of
platforms from 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 following section lists the changes in the MySQL source code since
the previous released version of MySQL 5.5.  It may also be viewed
online at:

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

----

D.1.2. Changes in MySQL 5.5.9

    Configuration Notes:

      * MySQL releases are now built on all platforms using CMake
        rather than the GNU autotools, so autotools support has been
        removed. For instructions on building MySQL with CMake, see
        Section 2.11, "Installing MySQL from Source." Third-party
        tools that need to extract the MySQL version number formerly
        found in configure.in can use the VERSION file. See Section
        2.11.6, "MySQL Configuration and Third-Party Tools."

    Functionality added or changed:

      * The mysqladmin and mysqldump clients now have --default-auth
        and --plugin-dir options for specifying which authentication
        plugin and plugin directory to use.
        (Bug#58139: http://bugs.mysql.com/bug.php?id=58139)

      * sql_priv.h now includes an OPTION_ALLOW_BATCH flag for the
        transaction_allow_batching
        (http://dev.mysql.com/doc/refman/5.1/en/server-system-variable
        s.html#sysvar_transaction_allow_batching) feature of MySQL
        Cluster. (Bug#57604: http://bugs.mysql.com/bug.php?id=57604)

      * Boolean system variables can be enabled at run time by setting
        them to the value ON or OFF, but previously this did not work
        at server startup. Now at startup such variables can be
        enabled by setting them to ON or TRUE. Any other nonnumeric
        variable is interpreted as OFF.
        (Bug#46393: http://bugs.mysql.com/bug.php?id=46393 improves on
        this such that ON, TRUE, OFF, and FALSE are recognized, and
        other values are invalid.)
        (Bug#51631: http://bugs.mysql.com/bug.php?id=51631)

    Bugs fixed:

      * Incompatible Change: When auto_increment_increment is greater
        than one, values generated by a bulk insert that reaches the
        maximum column value could wrap around rather producing an
        overflow error.
        As a consequence of the fix, it is no longer possible for an
        auto-generated value to be equal to the maximum BIGINT
        UNSIGNED value. It is still possible to store that value
        manually, if the column can accept it.
        (Bug#39828: http://bugs.mysql.com/bug.php?id=39828)

      * Important Change: Partitioning: Date and time functions used
        as partitioning functions now have the types of their operands
        checked; use of a value of the wrong type is now disallowed in
        such cases. In addition, EXTRACT(WEEK FROM col), where col is
        a DATE or DATETIME column, is now disallowed altogether
        because its return value depends on the value of the
        default_week_format system variable.
        (Bug#54483: http://bugs.mysql.com/bug.php?id=54483)
        See also Bug#57071: http://bugs.mysql.com/bug.php?id=57071.

      * Partitioning: InnoDB Storage Engine: The partitioning handler
        did not pass locking information to a table's storage engine
        handler. This caused high contention and thus slower
        performance when working with partitioned InnoDB tables.
        (Bug#59013: http://bugs.mysql.com/bug.php?id=59013)

      * InnoDB Storage Engine: When multiple InnoDB buffer pools were
        enabled, SHOW ENGINE INNODB commands displayed information
        about each one, but not summary information combining
        statistics for the entire buffer pool subsystem. Now, the
        aggregated information is displayed in the BUFFER POOL AND
        MEMORY section, and information about individual buffer pool
        instances is displayed in a new INDIVIDUAL BUFFER POOL INFO
        section. (Bug#58461: http://bugs.mysql.com/bug.php?id=58461)

      * InnoDB Storage Engine: The command to create a debug build
        (cmake -DWITH_DEBUG ...) now automatically sets the InnoDB
        debugging flag UNIV_DEBUG on all platforms. Formerly, the
        UNIV_DEBUG flag might not be set for Windows platforms with
        Visual Studio and not on OS X with Xcode.
        (Bug#58279: http://bugs.mysql.com/bug.php?id=58279)

      * InnoDB Storage Engine: In InnoDB status output, the value for
        I/O sum[] could be incorrect, displayed as a very large
        number. (Bug#57600: http://bugs.mysql.com/bug.php?id=57600)

      * InnoDB Storage Engine: It was not possible to query the
        information_schema.innodb_trx table while other connections
        were running queries involving BLOB types.
        (Bug#55397: http://bugs.mysql.com/bug.php?id=55397)

      * InnoDB Storage Engine: When the lowercase_system_names
        variable was set to 2, InnoDB could fail to restore a
        mysqldump dump of a table with foreign key constraints
        involving case-sensitive names.
        (Bug#55222: http://bugs.mysql.com/bug.php?id=55222)

      * InnoDB Storage Engine: The OPTIMIZE TABLE statement would
        reset the auto-increment counter for an InnoDB table. Now the
        auto-increment value is preserved across this operation.
        (Bug#18274: http://bugs.mysql.com/bug.php?id=18274)

      * Partitioning: A failed ALTER TABLE ... TRUNCATE PARTITION
        statement was still written to the binary log.
        (Bug#58147: http://bugs.mysql.com/bug.php?id=58147)

      * Partitioning: Failed ALTER TABLE ... PARTITION statements
        could cause memory leaks.
        (Bug#56380: http://bugs.mysql.com/bug.php?id=56380)
        See also Bug#46949: http://bugs.mysql.com/bug.php?id=46949,
        Bug#56996: http://bugs.mysql.com/bug.php?id=56996.

      * Replication: While an INSERT DELAYED statement with a single
        inserted value does not return any visible warnings, such a
        warning could be still written into the error log.
        (Bug#57666: http://bugs.mysql.com/bug.php?id=57666)
        See also Bug#49567: http://bugs.mysql.com/bug.php?id=49567.

      * Replication: When closing a session that used temporary
        tables, binary logging could sometimes fail with a spurious
        Failed to write the DROP statement for temporary tables to
        binary log.
        (Bug#57288: http://bugs.mysql.com/bug.php?id=57288)

      * Replication: Due to changes made in MySQL 5.5.3, settings made
        in the binlog_cache_size and max_binlog_cache_size server
        system variables affected both the binary log statement cache
        (also introduced in that version) and the binary log
        transactional cache (formerly known simply as the binary log
        cache). This meant that the resources used as a result of
        setting either or both of these variables were double the
        amount expected. To rectify this problem, these variables now
        affect only the transactional cache. The fix for this issue
        also introduces two new system variables
        binlog_stmt_cache_size and max_binlog_stmt_cache_size, which
        affect only the binary log statement cache.
        In addition, the Binlog_cache_use status variable was
        incremented whenever either cache was used, and
        Binlog_cache_disk_use was incremented whenever the disk space
        from either cache was used, which caused problems with
        performance tuning of the statement and transactional caches,
        because it was not possible to determine which of these was
        being exceeded when attempting to troubleshoot excessive disk
        seeks and related problems. This issue is solved by changing
        the behavior of these two status variables such that they are
        incremented only in response to usage of the binary log
        transactional cache, as well as by introducing two new status
        variables Binlog_stmt_cache_use and
        Binlog_stmt_cache_disk_use, which are incremented only by
        usage of the binary log statement cache.
        For more information, see Section 17.1.3.4, "System variables
        used with the binary log," and Section 5.1.6, "Server Status
        Variables."
        (Bug#57275: http://bugs.mysql.com/bug.php?id=57275)

      * Replication: By default, a value is generated for an
        AUTO_INCREMENT column by inserting either NULL or 0 into the
        column. Setting the NO_AUTO_VALUE_ON_ZERO server SQL mode
        suppresses this behavior for 0, so that it occurs only when
        NULL is inserted into the column.
        This behavior is also followed on a replication slave (by the
        slave SQL thread) when applying events that have been logged
        on the master using the statement-based format. However, when
        applying events that had been logged using the row-based
        format, NO_AUTO_VALUE_ON_ZERO was ignored, which could lead to
        an assertion.
        To fix this issue, the value of an AUTO_INCREMENT column is no
        longer generated when applying an event that was logged using
        the row-based row format, as this value is already contained
        in the changes applied on the slave.
        (Bug#56662: http://bugs.mysql.com/bug.php?id=56662)

      * Replication: The Binlog_cache_use and Binlog_cache_disk_use
        status variables were incremented twice by a change to a table
        using a transactional storage engine.
        (Bug#56343: http://bugs.mysql.com/bug.php?id=56343)

      * Replication: The BINLOG statement modified the values of
        session variables, which could lead to problems with
        operations such a point-in-time recovery. One such case
        occurred when replaying a row-based binary log which relied on
        setting foreign_key_checks = OFF on the session level in order
        to create and populate a set of InnoDB tables having foreign
        key constraints.
        (Bug#54903: http://bugs.mysql.com/bug.php?id=54903)

      * Replication: mysqlbinlog printed USE statements to its output
        only when the default database changed between events. To
        illustrate how this could cause problems, suppose that a user
        issued the following sequence of statements:
           CREATE DATABASE mydb;
           USE mydb;
           CREATE TABLE mytable (column_definitions);
           DROP DATABASE mydb;
           CREATE DATABASE mydb;
           USE mydb;
           CREATE TABLE mytable (column_definitions);
        When played back using mysqlbinlog, the second CREATE TABLE
        statement failed with Error: No Database Selected because the
        second USE statement was not played back, due to the fact that
        a database other than mydb was never selected.
        This fix insures that mysqlbinlog outputs a USE statement
        whenever it reads one from the binary log.
        (Bug#50914: http://bugs.mysql.com/bug.php?id=50914)

      * Replication: Previously, when a statement failed with a
        different error on the slave than on the master, the slave SQL
        thread displayed a message containing:

           + The error message for the master error code

           + The master error code

           + The error message for the slaves error code

           + The slave error code
        However, the slave has no information with which to fill in
        any print format specifiers for the master message, so it
        actually displayed the message format string. To make it
        clearer that the slave is not displaying the actual message as
        it appears on the master, the slave now indicates that the
        master part of the output is the message format, not the
        actual message. For example, previously the slave displayed
        information like this:
        Error: "Query caused different errors on master and slave.
        Error on master: 'Duplicate entry '%-.192s' for key %d'
        (1062), Error on slave: 'no error' (0). Default database:
        'test'. Query: 'insert into t1 values(1),(2)'" (expected
        different error codes on master and slave)
        Now the slave displays this:
        Error: "Query caused different errors on master and slave.
        Error on master: message format='Duplicate entry '%-.192s' for
        key %d' error code=1062 ; Error on slave: actual message='no
        error', error code=0. Default database: 'test'. Query: 'insert
        into t1 values(1),(2)'" (expected different error codes on
        master and slave)
        (Bug#46697: http://bugs.mysql.com/bug.php?id=46697)

      * Replication: When an error occurred in the generation of the
        name for a new binary log file, the error was logged but not
        shown to the user.
        (Bug#46166: http://bugs.mysql.com/bug.php?id=46166)
        See also Bug#37148: http://bugs.mysql.com/bug.php?id=37148,
        Bug#40611: http://bugs.mysql.com/bug.php?id=40611,
        Bug#43929: http://bugs.mysql.com/bug.php?id=43929,
        Bug#51019: http://bugs.mysql.com/bug.php?id=51019.

      * Comparisons of aggregate values with TIMESTAMP values were
        incorrect. (Bug#59330: http://bugs.mysql.com/bug.php?id=59330)

      * For DIV expressions, assignment of the result to multiple
        variables could cause a server crash.
        (Bug#59241: http://bugs.mysql.com/bug.php?id=59241)
        See also Bug#8457: http://bugs.mysql.com/bug.php?id=8457.

      * MIN(year_col) could return an incorrect result in some cases.
        (Bug#59211: http://bugs.mysql.com/bug.php?id=59211)

      * mysqlslap failed to check for a NULL return from
        mysql_store_result() and crashed trying to process the result
        set. (Bug#59109: http://bugs.mysql.com/bug.php?id=59109)

      * In a subquery, a UNION with no referenced tables (or only a
        reference to the virtual table dual) did not allow an ORDER BY
        clause. (Bug#58970: http://bugs.mysql.com/bug.php?id=58970)

      * Configuring MySQL with -DWITHOUT_PERFSCHEMA_STORAGE_ENGINE=1
        caused build failures.
        (Bug#58953: http://bugs.mysql.com/bug.php?id=58953)

      * Several Valgrind warnings were fixed.
        (Bug#58948: http://bugs.mysql.com/bug.php?id=58948,
        Bug#59021: http://bugs.mysql.com/bug.php?id=59021)

      * OPTIMIZE TABLE for an InnoDB table could raise an assertion if
        the operation failed because it had been killed.
        (Bug#58933: http://bugs.mysql.com/bug.php?id=58933)

      * If max_allowed_packet was set larger than 16MB, the server
        failed to reject too-large packets with "Packet too large"
        errors. (Bug#58887: http://bugs.mysql.com/bug.php?id=58887)

      * A NOT IN predicate with a subquery containing a HAVING clause
        could retrieve too many rows, when the subquery itself
        returned NULL.
        (Bug#58818: http://bugs.mysql.com/bug.php?id=58818)

      * EXPLAIN could crash for queries that accessed two derived
        tables. (Bug#58730: http://bugs.mysql.com/bug.php?id=58730)

      * On Solaris, the MySQL build failed if it was configured with
        debugging enabled.
        (Bug#58699: http://bugs.mysql.com/bug.php?id=58699)

      * Issuing EXPLAIN EXTENDED for a query that would use condition
        pushdown could cause mysqld to crash.
        (Bug#58553: http://bugs.mysql.com/bug.php?id=58553)

      * An assertion could be raised for queries for which the
        optimizer could choose between Index Merge range access or
        const ref access methods.
        (Bug#58456: http://bugs.mysql.com/bug.php?id=58456)

      * If MySQL was built with Visual Studio Express, the project
        wixca was not built.
        (Bug#58411: http://bugs.mysql.com/bug.php?id=58411)

      * EXPLAIN could crash for queries that used GROUP_CONCAT().
        (Bug#58396: http://bugs.mysql.com/bug.php?id=58396)

      * CMake polluted the source tree by writing installation-related
        temporary files there.
        (Bug#58372: http://bugs.mysql.com/bug.php?id=58372)

      * Security context references in sp_head.cc were rewritten for
        improved DTrace compatibility.
        (Bug#58350: http://bugs.mysql.com/bug.php?id=58350)

      * The ucs2 character set does not support characters outside the
        Basic Multilingual Plane (BMP), but converting a string
        containing such characters did not produce a
        conversion-failure warning.
        (Bug#58321: http://bugs.mysql.com/bug.php?id=58321)

      * A Valgrind failure occurred in fn_format when called from
        archive_discover.
        (Bug#58205: http://bugs.mysql.com/bug.php?id=58205)

      * CMake did not add LINK_LIBRARIES for MYSQL_ADD_PLUGIN for
        libmysqld. (Bug#58158: http://bugs.mysql.com/bug.php?id=58158)

      * An assertion could be raised if the server was closing a
        session at the same time the session was being killed by
        another thread.
        (Bug#58136: http://bugs.mysql.com/bug.php?id=58136)

      * Condition pushdown optimization could push down conditions
        with incorrect column references.
        (Bug#58134: http://bugs.mysql.com/bug.php?id=58134)

      * Configuration with maintainer mode enabled resulted in errors
        when compiling with icc.
        (Bug#57991: http://bugs.mysql.com/bug.php?id=57991,
        Bug#58871: http://bugs.mysql.com/bug.php?id=58871)

      * An ORDER BY clause was bound to the incorrect substatement
        when used in UNION context.
        (Bug#57986: http://bugs.mysql.com/bug.php?id=57986)

      * The BIT_AND() function could return incorrect results when a
        join returned no matching rows.
        (Bug#57954: http://bugs.mysql.com/bug.php?id=57954)

      * If the set of values aggregated with AVG(DISTINCT) contained a
        NULL value, the function result could be incorrect.
        (Bug#57932: http://bugs.mysql.com/bug.php?id=57932)

      * In rare cases, LIKE expressions failed for an indexed column
        that used a collation containing contractions.
        (Bug#57737: http://bugs.mysql.com/bug.php?id=57737)

      * Unnecessary subquery evaluation in contexts such as statement
        preparation or view creation could cause a server crash.
        (Bug#57703: http://bugs.mysql.com/bug.php?id=57703)

      * View creation could produce Valgrind warnings.
        (Bug#57352: http://bugs.mysql.com/bug.php?id=57352)

      * NULL geometry values could cause a crash in
        Item_func_spatial_collection::fix_length_and_dec.
        (Bug#57321: http://bugs.mysql.com/bug.php?id=57321)

      * 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#56769: http://bugs.mysql.com/bug.php?id=56769)

      * The cp1251 character set did not properly support the Euro
        sign (0x88). For example, converting a string containing this
        character to utf8 resulted in '?' rather than the utf8 Euro
        sign. (Bug#56639: http://bugs.mysql.com/bug.php?id=56639)

      * Some unsigned system variables could be displayed with
        negative values.
        (Bug#55794: http://bugs.mysql.com/bug.php?id=55794)

      * CREATE DATABASE and DROP DATABASE caused mysql --one-database
        to lose track of the statement-filtering context.
        (Bug#54899: http://bugs.mysql.com/bug.php?id=54899)

      * An assertion could be raised during concurrent execution of
        DROP DATABASE and REPAIR TABLE if the drop deleted a table's
        .TMD file at the same time the repair tried to read details
        from the old file that was just removed.
        A problem could also occur when DROP TABLE tried to remove all
        files belonging to a table at the same time REPAIR TABLE had
        just deleted the table's .TMD file.
        (Bug#54486: http://bugs.mysql.com/bug.php?id=54486)

      * After compilation from source, all header files were installed
        in the same directory, even those that should be installed
        into subdirectories of the installation include directory.
        (Bug#51925: http://bugs.mysql.com/bug.php?id=51925)

      * When mysqld printed crash dump information, it incorrectly
        indicated that some valid pointers were invalid.
        (Bug#51817: http://bugs.mysql.com/bug.php?id=51817)

      * On Mac OS X, a configuration error caused the preference pane
        to fail. (Bug#51264: http://bugs.mysql.com/bug.php?id=51264)

      * On FreeBSD, if mysqld was killed with a SIGHUP signal, it
        could corrupt InnoDB .ibd files.
        (Bug#51023: http://bugs.mysql.com/bug.php?id=51023)

      * An assertion could be raised if -1 was inserted into an
        AUTO_INCREMENT column by a statement writing more than one
        row. (Bug#50619: http://bugs.mysql.com/bug.php?id=50619)

      * If a client supplied a user name longer than the maximum 16
        characters allowed for names stored in the MySQL grant tables,
        all characters were being considered significant.
        Historically, only the first 16 characters were used to check
        for a match; this behavior was restored.
        (Bug#49752: http://bugs.mysql.com/bug.php?id=49752)

      * The my_seek() and my_tell() functions ignored the MY_WME flag
        when they returned an error, which could cause client programs
        to hang. (Bug#48451: http://bugs.mysql.com/bug.php?id=48451)

      * During assignment of values to system variables, legality
        checks on the value range occurred too late, preventing proper
        error checking.
        (Bug#43233: http://bugs.mysql.com/bug.php?id=43233)

      * On Solaris, time-related functions such as NOW() or SYSDATE()
        could return a constant value.
        (Bug#42054: http://bugs.mysql.com/bug.php?id=42054)

      * If the remote server for a FEDERATED table could not be
        accessed, queries for the INFORMATION_SCHEMA.TABLES table
        failed. (Bug#35333: http://bugs.mysql.com/bug.php?id=35333)

Enjoy!

On behalf of the MySQL Build Team,
Hery Ramilison

Thread
MySQL Community Server 5.5.9 has been releasedHery Ramilison8 Feb