MySQL Community Server 5.5.8 has been released

[Karen Langford]

Dear MySQL users,

We are proud to present to you the MySQL Database 5.5.8 GA release, the
first 5.5 production version of the world's most popular open source
database. MySQL 5.5.8 is recommended for use on production systems.

MySQL 5.5 includes several high-impact changes to address scalability
and performance issues in MySQL Database. 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
Edition at:

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

For information on installing MySQL 5.5.8 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 Database 5.5 is available in source and binary form for a number of
platforms from our download pages at:

http://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-8.html

----
D.1.1. Changes in MySQL 5.5.8 (03 December 2010)

   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:

     * Support for the IBMDB2I storage engine has been removed.
       (Bug#58079: http://bugs.mysql.com/bug.php?id=58079)

     * A --bind-address option has been added to a number of MySQL
       client programs: mysql, mysqldump, mysqladmin, mysqlbinlog,
       mysqlcheck, mysqlimport, and mysqlshow. This is for use on a
       computer having multiple network interfaces, and enables you
       to choose which interface is used to connect to the MySQL
       server.

   Bugs fixed:

     * Performance: InnoDB Storage Engine: Improved concurrency when
       several ANALYZE TABLE or SHOW TABLE STATUS statements are run
       simultaneously for InnoDB tables.
       (Bug#53046: http://bugs.mysql.com/bug.php?id=53046)

     * Incompatible Change: Previously, tables in the
       performance_schema database had uppercase names. This was
       incompatible with the lower_case_table_names system variable,
       and caused issues when the variable value was changed after
       installing or upgrading.
       Now performance_schema table names are lowercase, so they
       appear in uniform lettercase regardless of the
       lower_case_table_names setting. References to these tables in
       SQL statements should be given in lowercase. This is an
       incompatible change, but provides compatible behavior across
       different values of lower_case_table_names.
       If you upgrade to MySQL 5.5.8 from an earlier version of MySQL
       5.5, be sure to run mysql_upgrade (and restart the server) to
       change the names of existing performance_schema tables from
       uppercase to lowercase.
       (Bug#57609: http://bugs.mysql.com/bug.php?id=57609)

     * Incompatible Change: The following changes were made to the
       performance_schema.threads table for conformance with the
       implementation in MySQL 5.6:

          + ID column: Renamed to PROCESSLIST_ID, removed NOT NULL
            from definition.

          + NAME column: Changed from VARCHAR(64) to VARCHAR(128).
       (Bug#57154: http://bugs.mysql.com/bug.php?id=57154)

     * Incompatible Change: Deadlock occurred when a connection that
       had some table open through a HANDLER statement tried to
       update data through a DML statement while another connection
       tried to execute FLUSH TABLES WITH READ LOCK concurrently.
       Starvation of FLUSH TABLES WITH READ LOCK statements occurred
       when there was a constant load of concurrent DML statements in
       two or more connections.
       These problems resulted from the global read lock
       implementation, which was reimplemented with the following
       consequences:

          + To solve deadlock in event-handling code that was exposed
            by this patch, the LOCK_event_metadata mutex was replaced
            with metadata locks on events. As a result, DDL operations
            on events are now prohibited under LOCK TABLES. This is
            an incompatible change.

          + The global read lock (FLUSH TABLES WITH READ LOCK) no
            longer blocks DML and DDL on temporary tables. Before
            this patch, server behavior was not consistent in this
            respect: In some cases, DML/DDL statements on temporary
            tables were blocked; in others, they were not. Since the
            main use cases for FLUSH TABLES WITH READ LOCK are
            various forms of backups and temporary tables are not
            preserved during backups, the server now consistently
            allows DML/DDL on temporary tables under the global read
            lock.

          + Thread state names are now either Waiting for global read
            lock or Waiting for commit lock, depending on which stage
            FLUSH TABLES WITH READ LOCK is in.
       (Bug#57006: http://bugs.mysql.com/bug.php?id=57006,
       Bug#54673: http://bugs.mysql.com/bug.php?id=54673)

     * InnoDB Storage Engine: Values could be truncated in certain
       INFORMATION_SCHEMA columns, such as
       REFERENTIAL_CONSTRAINTS.REFERENCED_TABLE_NAME and
       KEY_COLUMN_USAGE.REFERENCED_TABLE_NAME.
       (Bug#57960: http://bugs.mysql.com/bug.php?id=57960)

     * InnoDB Storage Engine: For an InnoDB table created with
       ROW_FORMAT=COMPRESSED or ROW_FORMAT=DYNAMIC, a query using the
       READ UNCOMMITTED 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. (Bug#57799: http://bugs.mysql.com/bug.php?id=57799)

     * InnoDB Storage Engine: The server could stop with an assertion
       error on Windows Vista and Windows 7 systems.
       (Bug#57720: http://bugs.mysql.com/bug.php?id=57720)

     * InnoDB Storage Engine: A followup fix to
       Bug#54678: http://bugs.mysql.com/bug.php?id=54678. TRUNCATE
       TABLE could still cause a crash (assertion error) in the
       debug version of the server.
       (Bug#57700: http://bugs.mysql.com/bug.php?id=57700)

     * InnoDB Storage Engine: The InnoDB system tablespace could grow
       continually for a server under heavy load.
       (Bug#57611: http://bugs.mysql.com/bug.php?id=57611)

     * InnoDB Storage Engine: Heavy concurrent updates of a BLOB
       column in an InnoDB table could cause a hang.
       (Bug#57579: http://bugs.mysql.com/bug.php?id=57579)

     * InnoDB Storage Engine: The innodb_stats_on_metadata option
       could prevent the ANALYZE TABLE statement from running.
       (Bug#57252: http://bugs.mysql.com/bug.php?id=57252)

     * InnoDB Storage Engine: A query for an InnoDB table could
       return the wrong value if a column value was changed to a
       different case, and the column had a case-insensitive index.
       (Bug#56680: http://bugs.mysql.com/bug.php?id=56680)

     * InnoDB Storage Engine: An existing InnoDB could be switched to
       ROW_FORMAT=COMPRESSED implicitly by a KEY_BLOCK_SIZE clause in
       an ALTER TABLE statement. Now, the row format is only switched
       to compressed if there is an explicit ROW_FORMAT=COMPRESSED
       clause. on the ALTER TABLE statement.
       Any valid, non-default ROW_FORMAT parameter takes precedence
       over KEY_BLOCK_SIZE when both are specified. KEY_BLOCK_SIZE
       only enables ROW_FORMAT=COMPRESSED if ROW_FORMAT is not
       specified on either the CREATE TABLE or ALTER TABLE statement,
       or is specified as DEFAULT. In case of a conflict between
       KEY_BLOCK_SIZE and ROW_FORMAT clauses, the KEY_BLOCK_SIZE is
       ignored if innodb_strict_mode is off, and the statement causes
       an error if innodb_strict_mode is on.
       (Bug#56632: http://bugs.mysql.com/bug.php?id=56632)

     * InnoDB Storage Engine: The clause KEY_BLOCK_SIZE=0 is now
       allowed on CREATE TABLE and ALTER TABLE statements for InnoDB
       tables, regardless of the setting of innodb_strict_mode. The
       zero value has the effect of resetting the KEY_BLOCK_SIZE
       table parameter to its default value, depending on the
       ROW_FORMAT parameter, as if it had not been specified. That
       default is 8 if ROW_FORMAT=COMPRESSED. Otherwise,
       KEY_BLOCK_SIZE is not used or stored with the table
       parameters.
       As a consequence of this fix, ROW_FORMAT=FIXED is not allowed
       when the innodb_strict_mode is enabled.
       (Bug#56628: http://bugs.mysql.com/bug.php?id=56628)

     * InnoDB Storage Engine: A large number of foreign key
       declarations could cause the output of the SHOW CREATE
       STATEMENT statement to be truncated.
       (Bug#56143: http://bugs.mysql.com/bug.php?id=56143)

     * InnoDB Storage Engine: A compilation problem affected the
       InnoDB source code on NetBSD/sparc64.
       (Bug#53916: http://bugs.mysql.com/bug.php?id=53916)

     * InnoDB Storage Engine: Clarified the message when a CREATE
       TABLE statement fails because a foreign key constraint does
       not have the required indexes.
       (Bug#16290: http://bugs.mysql.com/bug.php?id=16290)

    * Partitioning: "Fast" ALTER TABLE operations (that do not
       involve a table copy) on a partitioned table could leave the
       table in an unusable state.
       (Bug#57985: http://bugs.mysql.com/bug.php?id=57985)

     * Partitioning: An INSERT ... ON DUPLICATE KEY UPDATE column = 0
       statement on an AUTO_INCREMENT column caused the debug server
       to crash. (Bug#57890: http://bugs.mysql.com/bug.php?id=57890)

     * Replication: Concurrent statements using a stored function and
       a DROP DATABASE statement that caused the same stored function
       to be dropped could cause statement-based replication to fail.
       This problem is resolved by making sure that DROP DATABASE
       takes an exclusive metadata lock on all stored functions and
       stored procedures that it causes to be dropped.
       (Bug#57663: http://bugs.mysql.com/bug.php?id=57663)
       See also Bug#30977: http://bugs.mysql.com/bug.php?id=30977.

     * Replication: When STOP SLAVE is issued, the slave SQL thread
       rolls back the current transaction and stops immediately if
       the transaction updates only tables which use transactional
       storage engines are updated. Previously, this occurred even
       when the transaction contained CREATE TEMPORARY TABLE
       statements, DROP TEMPORARY TABLE statements, or both, although
       these statements cannot be rolled back. Because temporary
       tables persist for the lifetime of a user session (in the
       case, the replication user), they remain until the slave is
       stopped or reset. When the transaction is restarted following
       a subsequent START SLAVE statement, the SQL thread aborts with
       an error that a temporary table to be created (or dropped)
       already exists (or does not exist, in the latter case).
       Following this fix, if an ongoing transaction contains CREATE
       TEMPORARY TABLE statements, DROP TEMPORARY TABLE statements,
       or both, the SQL thread now waits until the transaction ends,
       then stops.
       (Bug#56118: http://bugs.mysql.com/bug.php?id=56118)

     * Replication: If there exist both a temporary table and a
       non-temporary table having the same, updates normally apply
       only to the temporary table, with the exception of a CREATE
       TABLE ... SELECT statement that creates a non-temporary table
       having the same name as an existing temporary table. When such
       a statement was replicated using the MIXED logging format, and
       the statement was unsafe for row-based logging, updates were
       misapplied to the temporary table.
       Updates were also applied wrongly when a temporary table that
       used a transactional storage engine was dropped inside a
       transaction, followed by updates within the same transaction
       to a non-temporary table having the same name.
       (Bug#55478: http://bugs.mysql.com/bug.php?id=55478)
       See also Bug#47899: http://bugs.mysql.com/bug.php?id=47899,
       Bug#55709: http://bugs.mysql.com/bug.php?id=55709.

     * Replication: When making changes to relay log settings using
       CHANGE MASTER TO, the I/O cache was not cleared. This could
       result in replication failure when the slave attempted to read
       stale data from the cache and then stopped with an assertion.
       (Bug#55263: http://bugs.mysql.com/bug.php?id=55263)

     * Replication: Replication of SET and ENUM columns represented
       using more than 1 byte (that is, SET columns with more than 8
       members and ENUM columns with more than 256 constants) between
       platforms using different endianness failed when using the
       row-based format. This was because columns of these types are
       represented internally using integers, but the internal
       functions used by MySQL to handle them treated them as
       strings. (Bug#52131: http://bugs.mysql.com/bug.php?id=52131)
       See also Bug#53528: http://bugs.mysql.com/bug.php?id=53528.

     * Replication: Trying to read from a binary log containing a log
       event of an invalid type caused the slave to crash.
       (Bug#38718: http://bugs.mysql.com/bug.php?id=38718)

     * Replication: When replicating the mysql.tables_priv table, the
       Grantor column was not replicated, and was thus left empty on
       the slave. (Bug#27606: http://bugs.mysql.com/bug.php?id=27606)

     * Setting the read_only system variable at server startup did
       not work. (Bug#58669: http://bugs.mysql.com/bug.php?id=58669)

     * mysql_upgrade failed after an upgrade from MySQL 5.1.
       (Bug#58514: http://bugs.mysql.com/bug.php?id=58514)

     * When configuring the build with -DBUILD_CONFIG=mysql_release
       and building with Visual Studio Express, the build failed if
       signtool.exe was not present.
       (Bug#58313: http://bugs.mysql.com/bug.php?id=58313)

     * When configuring the build with -DBUILD_CONFIG=mysql_release
       on Linux, libaio is required, but the error message if it was
       missing was uninformative.
       (Bug#58227: http://bugs.mysql.com/bug.php?id=58227)

     * Use of NAME_CONST() in a HAVING clause caused a server crash.
       (Bug#58199: http://bugs.mysql.com/bug.php?id=58199)

     * BETWEEN did not use indexes for DATE or DATETIME columns.
       (Bug#58190: http://bugs.mysql.com/bug.php?id=58190)

     * Memory was allocated in fn_expand() for storing path names,
       but not freed anywhere.
       (Bug#58173: http://bugs.mysql.com/bug.php?id=58173)

     * In debug builds, inserting a FLOAT value into a CHAR(0) column
       could crash the server.
       (Bug#58137: http://bugs.mysql.com/bug.php?id=58137)

     * Failure to create a thread to handle a user connection could
       result in a server crash.
       (Bug#58080: http://bugs.mysql.com/bug.php?id=58080)

     * During configuration, ADD_VERSION_INFO in
       cmake/mysql_version.cmake failed if LINK_FLAGS was modified.
       (Bug#58074: http://bugs.mysql.com/bug.php?id=58074)

     * Performance Schema did not account for I/O for the binary log
       file (no I/O was counted).
       (Bug#58052: http://bugs.mysql.com/bug.php?id=58052)

     * Several compilation problems were fixed.
       (Bug#57992: http://bugs.mysql.com/bug.php?id=57992,
       Bug#57993: http://bugs.mysql.com/bug.php?id=57993,
       Bug#57994: http://bugs.mysql.com/bug.php?id=57994,
       Bug#57995: http://bugs.mysql.com/bug.php?id=57995,
       Bug#57996: http://bugs.mysql.com/bug.php?id=57996,
       Bug#57997: http://bugs.mysql.com/bug.php?id=57997,
       Bug#58057: http://bugs.mysql.com/bug.php?id=58057)

     * After creating a table with two foreign key constraints, the
       INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS table displayed
       only one of them.
       (Bug#57904: http://bugs.mysql.com/bug.php?id=57904)

     * Incorrect error handling raised an assertion if character set
       conversion wrapped an item that failed.
       (Bug#57882: http://bugs.mysql.com/bug.php?id=57882)

     * In debug builds, a missing DBUG_RETURN macro in sql/client.c
       caused mysql to be unable to connect to the server.
       (Bug#57744: http://bugs.mysql.com/bug.php?id=57744)

     * Clients using a client library older than MySQL 5.5.7 suffered
       loss of connection after executing mysql_change_user() while
       connected to a 5.5.7 server.
       (Bug#57689: http://bugs.mysql.com/bug.php?id=57689)

     * The MySQL-shared RPM package failed to provide the lowercase
       virtual identifier 'mysql-shared' in the RPM 'Provides' tags
       (usually used for backward compatibility).
       (Bug#57596: http://bugs.mysql.com/bug.php?id=57596)

     * For an upgrade to MySQL 5.5.7 from a previous release, the
       server exited if the mysql.proxies_priv table did not exist,
       making upgrades inconvenient. Now the server treats a missing
       proxies_priv table as equivalent to an empty table. However,
       after starting the server, you should still run mysql_upgrade
       to create the table.
       (Bug#57551: http://bugs.mysql.com/bug.php?id=57551)

     * SHOW PROCESSLIST displayed non-ASCII characters improperly.
       (Bug#57306: http://bugs.mysql.com/bug.php?id=57306)

     * Passing a string that was not null-terminated to UpdateXML()
       or ExtractValue() caused the server to fail with an assertion.
       (Bug#57279: http://bugs.mysql.com/bug.php?id=57279)

     * SET GLOBAL debug could cause a crash on Solaris if the server
       failed to open the trace file.
       (Bug#57274: http://bugs.mysql.com/bug.php?id=57274)

     * In debug builds, an assertion could be raised during
       conversion of strings to floating-point values.
       (Bug#57203: http://bugs.mysql.com/bug.php?id=57203)

     * A user with no privileges on a stored routine or the
       mysql.proc table could discover the routine's existence.
       (Bug#57061: http://bugs.mysql.com/bug.php?id=57061)

     * Queries executed using the Index Merge access method and a
       temporary file could return incorrect results.
       (Bug#56862: http://bugs.mysql.com/bug.php?id=56862)

     * The server could crash as a result of accessing freed memory
       when populating INFORMATION_SCHEMA.VIEWS if a view could not
       be opened properly.
       (Bug#56540: http://bugs.mysql.com/bug.php?id=56540)

     * Valgrind warnings about overlapping memory when
       double-assigning the same variable were corrected.
       (Bug#56138: http://bugs.mysql.com/bug.php?id=56138)

     * If a STOP SLAVE statement was issued while the slave SQL
       thread was executing a statement that invoked the SLEEP()
       function, both statements hung.
       (Bug#56096: http://bugs.mysql.com/bug.php?id=56096)

     * OPTIMIZE TABLE for InnoDB tables could raise an assertion.
       (Bug#55930: http://bugs.mysql.com/bug.php?id=55930)

     * Warnings raised by a trigger were not cleared upon successful
       completion. Now warnings are cleared if the trigger completes
       successfully, per the SQL standard.
       (Bug#55850: http://bugs.mysql.com/bug.php?id=55850)

     * For CMake builds, some parts of the source were unnecessarily
       compiled twice if the embedded server was built.
       (Bug#55647: http://bugs.mysql.com/bug.php?id=55647)

     * Boolean command options caused an error if given with an
       option value and the loose- option prefix.
       (Bug#54569: http://bugs.mysql.com/bug.php?id=54569)

     * An error in a stored procedure could leave the session in a
       different default database.
       (Bug#54375: http://bugs.mysql.com/bug.php?id=54375)

     * The CMake "wrapper" for configure (configure.pl) did not
       handle the --with-comment option properly.
       (Bug#52275: http://bugs.mysql.com/bug.php?id=52275)

     * Grouping by a TIME_TO_SEC() function result could cause a
       server crash or incorrect results. Grouping by a function
       returning a BLOB could cause an unexpected "Duplicate entry"
       error and incorrect result.
       (Bug#52160: http://bugs.mysql.com/bug.php?id=52160)

     * The find_files() function used by SHOW statements performed
       redundant and unnecessary memory allocation.
       (Bug#51208: http://bugs.mysql.com/bug.php?id=51208)

     * The Windows sample option files contained values more
       appropriate for Linux.
       (Bug#50021: http://bugs.mysql.com/bug.php?id=50021)

     * A failed RENAME TABLE operation could prevent a FLUSH TABLES
       WITH READ LOCK from completing.
       (Bug#47924: http://bugs.mysql.com/bug.php?id=47924)

     * Error messages for several internal conditions that should not
       occur were changed to instruct the user to file a bug if they
       do occur. (Bug#47027: http://bugs.mysql.com/bug.php?id=47027)

     * On file systems with case insensitive file names, and
       lower_case_table_names=2, the server could crash due to a
       table definition cache inconsistency.
       (Bug#46941: http://bugs.mysql.com/bug.php?id=46941)

     * Handling of host name lettercase in GRANT statements was
       inconsistent.
       (Bug#36742: http://bugs.mysql.com/bug.php?id=36742)

     * SET NAMES utf8 COLLATE utf8_sinhala_ci did not work.
       (Bug#26474: http://bugs.mysql.com/bug.php?id=26474)

     * The utf16_bin collation uses code-point order, not
       byte-by-byte order, as described at Section 9.1.14.1, "Unicode
       Character Sets." (The order was byte-by-byte in MySQL 5.5.7.)

Enjoy!

Karen Langford