MySQL Community Server 5.5.8 has been released
am 15.12.2010 18:03:03 von Karen LangfordDear 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
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org