D.1.2. Changes in MySQL 5.5.8 (03 December 2010 General Availability)

Configuration Notes:

Functionality added or changed:

  • Support for the IBMDB2I storage engine has been removed. (Bug#58079)

  • The following words are no longer reserved words the way they are in earlier MySQL 5.5 releases: SLOW, GENERAL, IGNORE_SERVER_IDS, MASTER_HEARTBEAT_PERIOD (Bug#57899)

  • The client/server protocol now includes a SERVER_QUERY_WAS_SLOW flag to indicate when a query is slow; that is, when query execution exceeds the value of the long_query_time system variable. (Bug#57058)

  • The time zone tables available at http://dev.mysql.com/downloads/timezones.html have been updated. These tables can be used on systems such as Windows or HP-UX that do not include zoneinfo files. (Bug#40230)

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

  • 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. If mysql_upgrade does not work, use this procedure:

    1. Stop mysqld.

    2. Remove the performance_schema/*.frm files from the data directory.

    3. Create a separate “dummy” MySQL 5.5.8 installation.

    4. Copy the performance_schema/*.frm files from the dummy installation to the installation you are upgrading.

    5. Restart mysqld and run mysqld_upgrade --force and check that it does not produce errors.

    6. Remove the dummy installation.

    (Bug#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)

  • Incompatible Change: Starvation of FLUSH TABLES WITH READ LOCK statements occurred when there was a constant load of concurrent DML statements in two or more connections. 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.

    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.

    • The set of thread states has changed:

      • Waiting for global metadata lock is replaced by Waiting for global read lock.

      • Previously, Waiting for release of readlock was used to indicate that DML/DDL statements were waiting for release of a read lock and Waiting to get readlock was used to indicate that FLUSH TABLES WITH READ LOCK was waiting to acquire a global read lock. Now Waiting for global read lock is used for both cases.

      • Previously, Waiting for release of readlock was used for all statements that caused an explicit or implicit commit to indicate that they were waiting for release of a read lock and Waiting for all running commits to finish was used by FLUSH TABLES WITH READ LOCK. Now Waiting for commit lock is used for both cases.

      • There are two other new states, Waiting for trigger metadata lock and Waiting for event metadata lock.

    (Bug#57006, Bug#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)

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

  • InnoDB Storage Engine: The server could stop with an assertion error on Windows Vista and Windows 7 systems. (Bug#57720)

  • InnoDB Storage Engine: A followup fix to Bug#54678. TRUNCATE TABLE could still cause a crash (assertion error) in the debug version of the server. (Bug#57700)

  • InnoDB Storage Engine: The InnoDB system tablespace could grow continually for a server under heavy load. (Bug#57611)

  • InnoDB Storage Engine: Heavy concurrent updates of a BLOB column in an InnoDB table could cause a hang. (Bug#57579)

  • InnoDB Storage Engine: The innodb_stats_on_metadata option could prevent the ANALYZE TABLE statement from running. (Bug#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)

  • InnoDB Storage Engine: An existing InnoDB table 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)

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

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

  • InnoDB Storage Engine: A compilation problem affected the InnoDB source code on NetBSD/sparc64. (Bug#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)

  • Partitioning: “FastALTER TABLE operations (that do not involve a table copy) on a partitioned table could leave the table in an unusable state. (Bug#57985)

  • Partitioning: An INSERT ... ON DUPLICATE KEY UPDATE column = 0 statement on an AUTO_INCREMENT column caused the debug server to crash. (Bug#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)

    See also Bug#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)

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

    See also Bug#47899, Bug#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)

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

    See also Bug#53528.

  • Replication: Trying to read from a binary log containing a log event of an invalid type caused the slave to crash. (Bug#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)

  • Setting the read_only system variable at server startup did not work. (Bug#58669)

  • mysql_upgrade failed after an upgrade from MySQL 5.1. (Bug#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)

  • With CMake 2.8.3, the -DBUILD_CONFIG=mysql_release option did not work. (Bug#58272)

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

  • Use of NAME_CONST() in a HAVING clause caused a server crash. (Bug#58199)

  • BETWEEN did not use indexes for DATE or DATETIME columns. (Bug#58190)

  • Memory was allocated in fn_expand() for storing path names, but not freed anywhere. (Bug#58173)

  • In debug builds, inserting a FLOAT value into a CHAR(0) column could crash the server. (Bug#58137)

  • Failure to create a thread to handle a user connection could result in a server crash. (Bug#58080)

  • During configuration, ADD_VERSION_INFO in cmake/mysql_version.cmake failed if LINK_FLAGS was modified. (Bug#58074)

  • Performance Schema did not account for I/O for the binary log file (no I/O was counted). (Bug#58052)

  • Several compilation problems were fixed. (Bug#57992, Bug#57993, Bug#57994, Bug#57995, Bug#57996, Bug#57997, Bug#58057)

  • After creation of a table with two foreign key constraints, the INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS table displayed only one of them. (Bug#57904)

  • Incorrect error handling raised an assertion if character set conversion wrapped an item that failed. (Bug#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)

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

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

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

  • SHOW PROCESSLIST displayed non-ASCII characters improperly. (Bug#57306)

  • Passing a string that was not null-terminated to UpdateXML() or ExtractValue() caused the server to fail with an assertion. (Bug#57279)

  • SET GLOBAL debug could cause a crash on Solaris if the server failed to open the trace file. (Bug#57274)

  • In debug builds, an assertion could be raised during conversion of strings to floating-point values. (Bug#57203)

  • If the file_name argument to the --defaults-file or --defaults-extra-file option was not a full path name, it could be interpreted incorrectly in some contexts and cause a server crash. Now the file_name argument is intrepreted as relative to the current working directory if given as a relative path name rather than as a full path name. (Bug#57108)

  • A user with no privileges on a stored routine or the mysql.proc table could discover the routine's existence. (Bug#57061)

  • Queries executed using the Index Merge access method and a temporary file could return incorrect results. (Bug#56862)

  • The server could crash inside memcpy() when reading certain Performance Schema tables. (Bug#56761, Bug#58003)

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

  • Valgrind warnings about overlapping memory when double-assigning the same variable were corrected. (Bug#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)

  • OPTIMIZE TABLE for InnoDB tables could raise an assertion. (Bug#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)

  • For CMake builds, some parts of the source were unnecessarily compiled twice if the embedded server was built. (Bug#55647)

  • In debug builds, an assertion could be raised if a send_eof() method was called after an error occurred. (Bug#54812)

  • Boolean command options caused an error if given with an option value and the loose- option prefix. (Bug#54569)

  • An error in a stored procedure could leave the session in a different default database. (Bug#54375)

  • The CMakewrapper” for configure (configure.pl) did not handle the --with-comment option properly. (Bug#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)

  • The find_files() function used by SHOW statements performed redundant and unnecessary memory allocation. (Bug#51208)

  • The Windows sample option files contained values more appropriate for Linux. (Bug#50021)

  • A failed RENAME TABLE operation could prevent a FLUSH TABLES WITH READ LOCK from completing. (Bug#47924)

  • Error messages for several delegate-related initialization error conditions that should not occur were changed to help identify the area of failure and to instruct the user to file a bug report if they do occur. A delegate is a set of internal data structures and algorithms. (Bug#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)

  • Handling of host name lettercase in GRANT statements was inconsistent. (Bug#36742)

  • SET NAMES utf8 COLLATE utf8_sinhala_ci did not work. (Bug#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.)

Copyright © 2010-2024 Platon Technologies, s.r.o.           Home | Man pages | tLDP | Documents | Utilities | About
Design by styleshout