Re: MySQL Server 5.5.3-m3 and MySQL Server 5.5.4-m3 have been released
Posted by: Daniel Fischer
Date: April 13, 2010 11:14AM
Date: April 13, 2010 11:14AM
Bugs fixed: * Performance: Replication: When writing events to the binary log, transactional events (that is, events that operate on transactional tables) are written to a thread-specific transaction cache, which is then written to the binary log on commit. In order to handle nontransactional events, there was a lock taken on the binary log (when entering the function MYSQL_BIN_LOG::write()), even when the event was written to the transaction cache instead of the binary log, causing a major bottleneck in replication performance. (Bug#42757: http://bugs.mysql.com/bug.php?id=42757) * Security Fix: The server crashed if an account with the CREATE ROUTINE privilege but not the EXECUTE privilege attempted to create a stored procedure. (Bug#44798: http://bugs.mysql.com/bug.php?id=44798) * Security Enhancement: When the DATA DIRECTORY or INDEX DIRECTORY clause of a CREATE TABLE statement referred to a subdirectory of the data directory via a symlinked component of the data directory path, it was accepted, when for security reasons it should be rejected. (Bug#39277: http://bugs.mysql.com/bug.php?id=39277) * Incompatible Change: Replication: The --binlog_format system variable can no longer be set inside a transaction. In other words, the binary logging format can no longer be changed while a transaction is in progress. (Bug#47863: http://bugs.mysql.com/bug.php?id=47863) * Incompatible Change: For debug builds, wttempts to execute RESET statements within a transaction that had acquired metadata locks led to an assertion failure. As a result of this bug fix, RESET statements now cause an implicit commit. (Bug#51336: http://bugs.mysql.com/bug.php?id=51336) * Incompatible Change: A deadlock occurred for this sequence of events: Session 1 locked a table using LOCK TABLES; Session 2 dropped the database containing the table; Session 1 created any database. A consequence of this bug fix is that CREATE DATABASE is disallowed within a session that has an active LOCK TABLES statement. (Bug#49988: http://bugs.mysql.com/bug.php?id=49988) * Incompatible Change: For application compatibility reasons, when sql_auto_is_null is 1, MySQL converts auto_inc_col IS NULL to auto_inc_col = LAST_INSERT_ID(). However, this was being done regardless of whether the predicate was alone or at the top level. Now it occurs only when it is a single top-level predicate. In conjunction with this bug fix, the default value of the sql_auto_is_null system variable has been changed from 1 to 0, which may cause incompatibilities with existing applications. (Bug#41371: http://bugs.mysql.com/bug.php?id=41371) * Incompatible Change: The parser accepted illegal syntax in a FOREIGN KEY clause: + Multiple MATCH clauses. + Multiple ON DELETE clauses. + Multiple ON UPDATE clauses. + MATCH clauses specified after ON UPDATE or ON DELETE. In case of multiple redundant clauses, this leads to confusion, and implementation-dependent results. These illegal syntaxes are now properly rejected. Existing applications that used them will require adjustment. (Bug#34455: http://bugs.mysql.com/bug.php?id=34455) * Incompatible Change: The Locked thread state was equivalent to the Table lock state and has been removed. It no longer appears in SHOW PROCESSLIST output. (Bug#28870: http://bugs.mysql.com/bug.php?id=28870) * Incompatible Change: Several changes were made to the processing of multiple-table DELETE statements: + Statements could not perform cross-database deletes unless the tables were referred to without using aliases. This limitation has been lifted and table aliases now are allowed. + Previously, alias declarations could be given for tables elsewhere than in the table_references part of the syntax. This could lead to ambiguous statements that have unexpected results such as deleting rows from the wrong table. Example: DELETE FROM t1 AS a2 USING t1 AS a1 INNER JOIN t2 AS a2; Now alias declarations can be declared only in the table_references part. Elsewhere in the statement, alias references are allowed but not alias declarations. + Alias resolution was improved so that it is no longer possible to have inconsistent or ambiguous aliases for tables. Statements containing alias constructs that are no longer allowed must be rewritten. (Bug#27525: http://bugs.mysql.com/bug.php?id=27525) See also Bug#30234: http://bugs.mysql.com/bug.php?id=30234. * Incompatible Change: DROP TABLE now is allowed only if you have acquired a WRITE lock with LOCK TABLES, or if you hold no locks, or if the table is a TEMPORARY table. Previously, if other tables were locked, you could drop a table with a read lock or no lock, which could lead to deadlocks between clients. The new stricter behavior means that some usage scenarios will fail when previously they did not. (Bug#25858: http://bugs.mysql.com/bug.php?id=25858) * Incompatible Change: If a data definition language (DDL) statement occurred for a table that was being used by another session in an active transaction, statements could be written to the binary log in the wrong order. For example, this could happen if DROP TABLE occurred for a table being used in a transaction. This is now prevented by deferring release of metadata locks on tables used within a transaction until the transaction ends. This bug fix results in some incompatibilities with previous versions: + A table that is being used by a transaction within one session cannot be used in DDL statements by other sessions until the transaction ends. + FLUSH TABLES is disallowed when there is an active LOCK TABLES ... READ. Use FLUSH TABLES tbl_list WITH READ LOCK instead. This causes a problem with mysqlhotcopy, fixed in Bug#42465: http://bugs.mysql.com/bug.php?id=42465. (Bug#989: http://bugs.mysql.com/bug.php?id=989, Bug#39675: http://bugs.mysql.com/bug.php?id=39675) * Important Change: Replication: For an engine that supported only row-based replication, replication stopped with an error when executing row events. For information about changes in how the binary logging format is determined in relation to statement type and storage engine logging capabilities, see Section 5.2.4.3, "Mixed Binary Logging Format." As part of the fix for this issue, the EXAMPLE storage engine is now changed so that it supports statement-based logging only. Previously, it supported row-based logging only. (Bug#39934: http://bugs.mysql.com/bug.php?id=39934) * Partitioning: When using a debug build of MySQL, if a query against a partitioned table having an index on one or more DOUBLE columns used that index, the server failed with an assertion. (Bug#45816: http://bugs.mysql.com/bug.php?id=45816) * Partitioning: The first time that a query against the INFORMATION_SCHEMA.TABLES table for partitioned tables using the ARCHIVE engine was run, it returned invalid data. If the server had been restarted since such a table had been created, or if the table had never actually been opened, its DATA_LENGTH was reported as 0 bytes. (The second and subsequent attempts to issue the same query returned the expected result.) (Bug#44622: http://bugs.mysql.com/bug.php?id=44622) * Partitioning: ALTER TABLE on a partitioned table caused unnecessary deadlocks. (Bug#43867: http://bugs.mysql.com/bug.php?id=43867) See also Bug#46654: http://bugs.mysql.com/bug.php?id=46654. * Partitioning: Attempting to drop a partitioned table from one connection while waiting for the completion of an ALTER TABLE that had been issued from a different connection, and that changed the storage engine used by the table, could cause the server to crash. (Bug#42438: http://bugs.mysql.com/bug.php?id=42438) * Partitioning: After attempting to create a duplicate index on a partitioned table (and having the attempt fail as expected), a subsequent attempt to create a new index on the table caused the server to hang. (Bug#40181: http://bugs.mysql.com/bug.php?id=40181) * Partitioning: When used on a partitioned table, ALTER TABLE produced the wrong error message when the name of a nonexistent storage engine was used in the ENGINE clause. (Bug#35765: http://bugs.mysql.com/bug.php?id=35765) * Partitioning: When one user was in the midst of a transaction on a partitioned table, a second user performing an ALTER TABLE on this table caused the server to hang. (Bug#34604: http://bugs.mysql.com/bug.php?id=34604) * Partitioning: Portions of the partitioning code were refactored in response to potential regression issues uncovered while working on the fix for Bug#31210: http://bugs.mysql.com/bug.php?id=31210. (Bug#32115: http://bugs.mysql.com/bug.php?id=32115) See also Bug#40281: http://bugs.mysql.com/bug.php?id=40281. * Replication: When using the row-based or mixed replication format with a debug build of the MySQL server, inserts into columns using the UTF32 character set on the master caused the slave to crash. (Bug#51787: http://bugs.mysql.com/bug.php?id=51787) See also Bug#51716: http://bugs.mysql.com/bug.php?id=51716. * Replication: When using the row-based or mixed replication format, column values using the UTF16 character set on the master were padded incorrectly on the slave. (Bug#51716: http://bugs.mysql.com/bug.php?id=51716) See also Bug#51787: http://bugs.mysql.com/bug.php?id=51787. * Replication: An issue internal to the code, first seen in Bug#49132: http://bugs.mysql.com/bug.php?id=49132 but not completely resolved in the fix for that bug, was removed. This should prevent similar issues to those in the previous bug with binlog_format changes following DDL statements. For developers working with the MySQL Server code: the public class variable THD::current_stmt_binlog_row_based was supposed to have been removed as part of the fix for Bug#39934: http://bugs.mysql.com/bug.php?id=39934, but was still present in the code. If a developer later tried to use this variable, it could cause the previous issues to re-occur, and possibly new ones to arise. The variable has now been removed; the previously added class functions THD::is_current_stmt_binlog_format_row(), THD::set_current_stmt_binlog_format_row(), and THD::clear_current_stmt_binlog_format_row() should be used instead. (Bug#51021: http://bugs.mysql.com/bug.php?id=51021) * Replication: Adding an index to a table on the master caused the slave to stop logging slow queries to the slow query log. (Bug#50620: http://bugs.mysql.com/bug.php?id=50620) * Replication: On a replication slave, a race condition between the I/O thread and FLUSH LOGS could crash the server. (Bug#50364: http://bugs.mysql.com/bug.php?id=50364) * Replication: If a CHANGE MASTER TO statement set MASTER_HEARTBEAT_PERIOD to 30 or higher, Slave_received_heartbeats did not increase on the slave. This caused the slave to reconnect before the time indicated by slave_net_timeout had elapsed. This issue affected big-endian 64-bit platforms such as Solaris/SPARC. (Bug#50296: http://bugs.mysql.com/bug.php?id=50296) * Replication: The error message given when trying to replicate (using statement-based mode) insertions into an AUTO_INCREMENT column by a stored function or a trigger was improved. (Bug#50192: http://bugs.mysql.com/bug.php?id=50192) * Replication: The server could deadlock when FLUSH LOGS was executed concurrently with DML statements. To fix this problem, nontransactional changes are now always flushed before transactional changes. (Bug#50038: http://bugs.mysql.com/bug.php?id=50038) * Replication: Metadata for GEOMETRY fields was not properly stored by the slave in its definitions of tables. (Bug#49836: http://bugs.mysql.com/bug.php?id=49836) See also Bug#48776: http://bugs.mysql.com/bug.php?id=48776. * Replication: Column length information generated by InnoDB did not match that generated by MyISAM, which caused invalid metadata to be written to the binary log when trying to replicate BIT columns. (Bug#49618: http://bugs.mysql.com/bug.php?id=49618) * Replication: Statement-based replication of user variables having numeric data types did not always work correctly. (Bug#49562: http://bugs.mysql.com/bug.php?id=49562) * Replication: When using the semi-synchronous replication plugin on Windows, the wait time calculated when the master was waiting for reply from the slave was incorrect. In addition, when the wait time was less than the current time, the master did not wait for a reply at all. This issue was caused by the fact that a different internal function was used to get current time by the plugin on Windows as opposed to other platforms, and this function was not correctly implemented. Now the Windows version of the plugin uses the same function as other platforms for this purpose. (Bug#49557: http://bugs.mysql.com/bug.php?id=49557) * Replication: Due to a change in the format of the information used by the slave to connect to the master, which could cause to reject connection attempts to older masters by newer slaves. (Bug#49259: http://bugs.mysql.com/bug.php?id=49259) This regression was introduced by Bug#13963: http://bugs.mysql.com/bug.php?id=13963. * Replication: When using row-based logging, a failing INSERT...SELECT statement on a nontransactional table was not flagged correctly, such that, if a rollback was requested and no other nontransactional table had been updated, nothing was written to the binary log. (Bug#47175: http://bugs.mysql.com/bug.php?id=47175) See also Bug#40278: http://bugs.mysql.com/bug.php?id=40278. * Replication: When using row-based replication, the incomplete logging of a group of events involving both transaction and nontransactional tables could cause STOP SLAVE to hang. (Bug#45940: http://bugs.mysql.com/bug.php?id=45940) See also Bug#319: http://bugs.mysql.com/bug.php?id=319, Bug#38205: http://bugs.mysql.com/bug.php?id=38205. * Replication: There were two related issues concerning handling of unsafe statements and setting of the binary logging format when there were open temporary tables on the master, and the existing replication format was row-based or mixed: 1. When using binlog_format=ROW, and an unsafe statement was executed while there were open temporary tables on the master, the statement SET @@session.binlog_format = MIXED failed with the error Cannot switch out of the row-based binary log format when the session has open temporary tables. 2. When using binlog_format=MIXED, and an unsafe statement was executed while there were open temporary tables on the master, the statement SET @@session.binlog_format = STATEMENT caused any subsequent DML statements to be written to the binary log using the row-based format instead of the statement-based format. (Bug#45855: http://bugs.mysql.com/bug.php?id=45855, Bug#45856: http://bugs.mysql.com/bug.php?id=45856) * Replication: Statements that updated AUTO_INCREMENT columns in multiple tables were logged using the row-based format when --binlog_format was set to MIXED, but did not cause an Unsafe statement warning to be generated when --binlog_format was set to STATEMENT. (Bug#45827: http://bugs.mysql.com/bug.php?id=45827) See also Bug#39934: http://bugs.mysql.com/bug.php?id=39934. * Replication: Even though INSERT DELAYED statements are unsafe for statement-based replication, they caused the statement only to be logged in row format when the binary logging format was MIXED, but did not cause a warning to be generated when the binary logging format was STATEMENT. (Bug#45825: http://bugs.mysql.com/bug.php?id=45825) * Replication: When using MIXED binary logging format, statements containing a LIMIT clause and occurring in stored routines were not written to the log as row events. (Bug#45785: http://bugs.mysql.com/bug.php?id=45785) * Replication: When using statement-based replication, database-level character sets were not always honored by the replication SQL thread. This could cause data inserted on the master using LOAD DATA to be replicated using the wrong character set. Note: This was not an issue when using row-based replication. (Bug#45516: http://bugs.mysql.com/bug.php?id=45516) * Replication: STOP SLAVE did not flush the relay log or the master.info or relay-log.info files, which could lead to corruption if the server crashed. (Bug#44188: http://bugs.mysql.com/bug.php?id=44188) * Replication: Large transactions and statements could corrupt the binary log if the size of the cache (as set by max_binlog_cache_size) was not large enough to store the changes. Now, for transactions that do not fit into the cache, the statement is not logged, and the statement generates an error instead. For nontransactional changes that do not fit into the cache, the statement is also not logged --- an incident event is logged after committing or rolling back any pending transaction, and the statement then raises an error. Note: If a failure occurs before the incident event is written the binary log, the slave does not stop, and the master does not report any errors. (Bug#43929: http://bugs.mysql.com/bug.php?id=43929) See also Bug#37148: http://bugs.mysql.com/bug.php?id=37148. * Replication: On Windows, RESET MASTER failed in the event of a missing binlog file rather than issuing a warning and completing the rest of the statement. (Bug#42150: http://bugs.mysql.com/bug.php?id=42150, Bug#42218: http://bugs.mysql.com/bug.php?id=42218) * Replication: Executing the sequence of statements RESET SLAVE, RESET MASTER, and FLUSH LOGS, when binary log or relay log files listed in the index file could not be found, could cause the server to crash. This could happen, for example, when these files had been moved or deleted manually. (Bug#41902: http://bugs.mysql.com/bug.php?id=41902) * Replication: MySQL creates binary logs in a numbered sequence, with a maximum possible 4294967295 concurrent log files, 4294967295 being the maximum value for an unsigned long integer. However, binary log file extensions were turned into negative numbers once the variable used to hold the value reached the maximum value for a signed long integer (2147483647). Consequently, when the sequence value was incremented to the next (negative) number, this caused MySQL to try to create the file using a .000000 extension, causing the server to fail since this file already existed. Negative file extensions are now disallowed, and an error is returned when the limit is reached. In addition, FLUSH LOGS now also reports warnings to the user, if the extension number has reached the limit, and warnings are printed to the error log when the limit is approaching. (Bug#40611: http://bugs.mysql.com/bug.php?id=40611) * Replication: Issuing concurrent STOP SLAVE, START SLAVE, and RESET SLAVE statements using different connections caused the replication slave to crash. (Bug#38716: http://bugs.mysql.com/bug.php?id=38716) See also Bug#38715: http://bugs.mysql.com/bug.php?id=38715, Bug#44312: http://bugs.mysql.com/bug.php?id=44312. * Replication: A slave compiled using --with-libevent and run with --thread-handling=pool-of-threads could sometimes crash. (Bug#36929: http://bugs.mysql.com/bug.php?id=36929) * Replication: mysqlbinlog sometimes failed when trying to create temporary files; this was because it ignored the specified temp file directory and tried to use the system /tmp directory instead. (Bug#35546: http://bugs.mysql.com/bug.php?id=35546) See also Bug#35543: http://bugs.mysql.com/bug.php?id=35543. * Replication: A CHANGE MASTER TO statement with no MASTER_HEARTBEAT_PERIOD option failed to reset the heartbeat period to its default value. (Bug#34686: http://bugs.mysql.com/bug.php?id=34686) * Replication: Formerly, only slaves that had been started with the --report-hosts option were visible in the output of SHOW SLAVE HOSTS. Now, all slaves that are registered with the master appear in SHOW SLAVE HOSTS output. (Bug#13963: http://bugs.mysql.com/bug.php?id=13963) See also Bug#21132: http://bugs.mysql.com/bug.php?id=21132, Bug#21869: http://bugs.mysql.com/bug.php?id=21869. * mysqld_multi failed due to a syntax error in the script. (Bug#51468: http://bugs.mysql.com/bug.php?id=51468) * On some Unix/Linux platforms, an error during build from source could be produced, referring to a missing LT_INIT program. This is due to versions of libtool 2.1 and earlier. (Bug#51009: http://bugs.mysql.com/bug.php?id=51009) * Referring to a subquery result in a HAVING clause could produce incorrect results. (Bug#50995: http://bugs.mysql.com/bug.php?id=50995) * Use of filesort plus the join cache normally is preferred to a full index scan. But it was used even if the index is clustered, in which case, the clustered index scan can be faster. (Bug#50843: http://bugs.mysql.com/bug.php?id=50843) * For debug builds, SHOW BINARY LOGS caused an assertion to be raised if binary logging was not enabled. (Bug#50780: http://bugs.mysql.com/bug.php?id=50780) * The server did not recognize that the stored procedure cache became invalid if a view was created or modified within a procedure, resulting in a crash. (Bug#50624: http://bugs.mysql.com/bug.php?id=50624) * Incorrect handling of BIT columns in temporary tables could lead to spurious duplicate-key errors. (Bug#50591: http://bugs.mysql.com/bug.php?id=50591) * The second or subsequent invocation of a stored procedure containing DROP TRIGGER could cause a server crash. (Bug#50423: http://bugs.mysql.com/bug.php?id=50423) * Full-text queries that used the truncation operator (*) could enter an infinite loop. (Bug#50351: http://bugs.mysql.com/bug.php?id=50351) * For debug builds, an assertion was incorrectly raised in the optimizer when matching ORDER BY expressions. (Bug#50335: http://bugs.mysql.com/bug.php?id=50335) * Queries optimized with GROUP_MIN_MAX did not clean up KEYREAD optimizations properly, causing subsequent queries to return incomplete rows. (Bug#49902: http://bugs.mysql.com/bug.php?id=49902) * mysql --show-warnings crashed if the server connection was lost. (Bug#49646: http://bugs.mysql.com/bug.php?id=49646) * For string-valued system variables containing multibyte characters, the byte length was used in contexts where the character length was more appropriate. (Bug#49645: http://bugs.mysql.com/bug.php?id=49645) * SHOW VARIABLES did not correctly display string-valued system variables that contained \0 characters. (Bug#49644: http://bugs.mysql.com/bug.php?id=49644) * MySQL program option-processing code incorrectly displayed some options when printing ambiguous-option errors. (Bug#49640: http://bugs.mysql.com/bug.php?id=49640) * For dynamic format MyISAM tables containing LONGTEXT columns, a bulk INSERT ... ON DUPLICATE KEY UPDATE or bulk REPLACE could cause corruption. (Bug#49628: http://bugs.mysql.com/bug.php?id=49628) * Setting binlog_format to DEFAULT assigned a value different from the default. (Bug#49540: http://bugs.mysql.com/bug.php?id=49540) * For debug builds, with sql_safe_updates enabled, a multiple-table UPDATE with the IGNORE modifier could raise an assertion. (Bug#49534: http://bugs.mysql.com/bug.php?id=49534) * EXPLAIN EXTENDED crashed trying to print column names for a subquery in the FROM clause when the table had gone out of scope. (Bug#49487: http://bugs.mysql.com/bug.php?id=49487) * mysqltest no longer lets you execute an SQL statement on a connection after doing a send command, unless you do a reap first. This was previously accepted but could produce unpredictable results. (Bug#49269: http://bugs.mysql.com/bug.php?id=49269) * Valgrind warnings for several logging messages were corrected. (Bug#49130: http://bugs.mysql.com/bug.php?id=49130) * For debug builds on Windows, warnings about incorrect use of debugging directives were written to the error log. The directives were rewritten to eliminate these messages. (Bug#49025: http://bugs.mysql.com/bug.php?id=49025) * On POSIX systems, calls to select() with a file descriptor set larger than FD_SETSIZE resulted in unpredictable I/O errors; for example, when a large number of tables required repair. (Bug#48929: http://bugs.mysql.com/bug.php?id=48929) * A dependent subquery containing COUNT(DISTINCT col_name)) could be evaluated incorrectly. (Bug#48920: http://bugs.mysql.com/bug.php?id=48920) * Building MySQL on Fedora Core 12 64-bit failed, due to errors in comp_err. (Bug#48864: http://bugs.mysql.com/bug.php?id=48864) * If a stored function contained a RETURN statement with an ENUM value in the ucs2 character set, SHOW CREATE FUNCTION and SELECT DTD_IDENTIFIER FROM INFORMATION_SCHEMA.ROUTINES returned incorrect values. (Bug#48766: http://bugs.mysql.com/bug.php?id=48766) * An ARZ file missing from the database directory caused the server to crash. (Bug#48757: http://bugs.mysql.com/bug.php?id=48757) * Running SHOW CREATE TABLE on a view v1 that contained a function which accessed another view v2 could trigger a infinite loop if the view (v2) referenced within the function caused a warning to be raised while being opened. (Bug#48449: http://bugs.mysql.com/bug.php?id=48449) * Invalid memory reads could occur following a query that referenced a MyISAM tale multiple times with a write lock. (Bug#48438: http://bugs.mysql.com/bug.php?id=48438) * If a prepared statement using a merged view referencing an INFORMATION_SCHEMA table was executed, no metadata lock of the view was taken. Consequently, it was possible for concurrent DDL statements on the view to execute and cause statements to be written in the wrong order to the binary log. (Bug#48315: http://bugs.mysql.com/bug.php?id=48315) * For debug builds, creating a view containing a row constructor caused an assertion to be raised. (Bug#48294: http://bugs.mysql.com/bug.php?id=48294) * An aliasing violation in the C API could lead to a crash. (Bug#48284: http://bugs.mysql.com/bug.php?id=48284) * Slow CALL statements were not always logged to the slow query log because execution time for multiple-statement stored procedures was assessed incorrectly. (Bug#47905: http://bugs.mysql.com/bug.php?id=47905) * For debug builds, killing a SELECT retrieving from a view that was processing a function caused an assertion to be raised. (Bug#47736: http://bugs.mysql.com/bug.php?id=47736) * Failure to open a view with a nonexistent DEFINER was improperly handled and the server would crash later attempting to lock the view. (Bug#47734: http://bugs.mysql.com/bug.php?id=47734) * If a prepared statement used both a MERGE table and a stored function or trigger, execution sometimes failed with a No such table error. (Bug#47648: http://bugs.mysql.com/bug.php?id=47648) * CREATE VIEW raised an assertion if a temporary table existed with the same name as the view. (Bug#47635: http://bugs.mysql.com/bug.php?id=47635) * If a temporary table was created with the same name as a view referenced in a stored routine, routine execution could raise an assertion. (Bug#47313: http://bugs.mysql.com/bug.php?id=47313) * Selecting from the process list in the embedded server caused a crash. (Bug#47304: http://bugs.mysql.com/bug.php?id=47304) See also Bug#43733: http://bugs.mysql.com/bug.php?id=43733. * Programs did not exit if the option file specfied by --defaults-file was not found. (Bug#47216: http://bugs.mysql.com/bug.php?id=47216) * Attempts to print octal numbers with my_vsnprintf() could cause a crash. (Bug#47212: http://bugs.mysql.com/bug.php?id=47212) * Corrected a potential problem of unintended overwriting of files when the MY_DONT_OVERWRITE_FILE flag was used. (Bug#47126: http://bugs.mysql.com/bug.php?id=47126) * Deadlock occurred if one session was running a multiple-statement transaction that involved a single partitioned table and another session attempted to alter the table. (Bug#46654: http://bugs.mysql.com/bug.php?id=46654) * Valgrind warnings about memory allocation overruns for handling CREATE FUNCTION statements for UDFs were corrected. (Bug#46570: http://bugs.mysql.com/bug.php?id=46570) * The server could crash attempting to flush privileges after receipt of a SIGHUP signal. (Bug#46495: http://bugs.mysql.com/bug.php?id=46495) * HANDLER OPEN followed by TRUNCATE TABLE could cause a server crash. (Bug#46452: http://bugs.mysql.com/bug.php?id=46452) See also Bug#20667: http://bugs.mysql.com/bug.php?id=20667. * If INSERT INTO tbl_name invoked a stored function that modified tbl_name, the server crashed. (Bug#46374: http://bugs.mysql.com/bug.php?id=46374) * For queries that used GROUP_CONCAT(DISTINCT ...), the value of max_heap_table_size was used for memory allocation, which could be excessive. Now the minimum of max_heap_table_size and tmp_table_size is used. (Bug#46018: http://bugs.mysql.com/bug.php?id=46018) * Improperly closing tables when INSERT DELAYED needed to reopen tables could cause an assertion failure. (Bug#45949: http://bugs.mysql.com/bug.php?id=45949) See also Bug#18484: http://bugs.mysql.com/bug.php?id=18484. * Grouping by a subquery in a query with a DISTINCT aggregate function led to incorrect and unordered grouping values. (Bug#45640: http://bugs.mysql.com/bug.php?id=45640) * For an IPv6-enabled MySQL server, privileges specified using standard IPv4 addresses for hosts were not matched (only IPv4-mapped addresses were handled correctly). As part of the fix for this bug, a new build option --disable-ipv6 has been introduced. Compiling MySQL with this option causes all IPv6-specific code in the server to be ignored. Important: If the server has been compiled using --disable-ipv6, it is not able to resolve hostnames correctly when run in an IPv6 environment. (Bug#45606: http://bugs.mysql.com/bug.php?id=45606) See also Bug#38247: http://bugs.mysql.com/bug.php?id=38247, Bug#43006: http://bugs.mysql.com/bug.php?id=43006, Bug#45283: http://bugs.mysql.com/bug.php?id=45283, Bug#45584: http://bugs.mysql.com/bug.php?id=45584. * The hostname cache failed to work correctly. (Bug#45584: http://bugs.mysql.com/bug.php?id=45584) See also Bug#38247: http://bugs.mysql.com/bug.php?id=38247, Bug#43006: http://bugs.mysql.com/bug.php?id=43006, Bug#45283: http://bugs.mysql.com/bug.php?id=45283, Bug#45606: http://bugs.mysql.com/bug.php?id=45606. * A Windows Installation using the GUI installer could fail. This was due to an step in the MSI installer that could fail to execute correctly on some environments. (Bug#45418: http://bugs.mysql.com/bug.php?id=45418) * Propagation of a large unsigned numeric constant in WHERE expressions could lead to incorrect results. This also affected EXPLAIN EXTENDED, which printed incorrect numeric constants in such transformed WHERE expressions. (Bug#45360: http://bugs.mysql.com/bug.php?id=45360) * There was no timeout for attempts to acquire metadata locks (for example, a DROP TABLE attempt for a table that was open in another transaction would not time out). To handle such situations, there is now a lock_wait_timeout system variable that specifies the timeout in seconds for attempts to acquire metadata locks. The allowed values range from 1 to 3153600 (1 year). The default is 3153600. This timeout applies to all statements that use metadata locks. These include DML and DDL operations on tables, views, stored procedures, and stored functions, as well as LOCK TABLES, FLUSH TABLES WITH READ LOCK, and HANDLER statements. The timeout value applies separately for each metadata lock attempt. A given statement can require more than one lock, so it is possible for the statement to block for longer than the lock_wait_timeout value before reporting a timeout error. When lock timeout occurs, ER_LOCK_WAIT_TIMEOUT is reported. lock_wait_timeout does not apply to delayed inserts, which always execute with a timeout of 1 year. This is done to avoid unnecessary timeouts because a session that issues a delayed insert receives no notification of delayed insert timeouts. In addition, the unused table_lock_wait_timeout system variable was removed. (Bug#45225: http://bugs.mysql.com/bug.php?id=45225) * Valgrind warnings about uninitialized variables in optimizer code were corrected. (Bug#45195: http://bugs.mysql.com/bug.php?id=45195) * Killing a delayed-insert thread could cause a server crash. (Bug#45067: http://bugs.mysql.com/bug.php?id=45067) * Execution of FLUSH TABLES or FLUSH TABLES WITH READ LOCK concurrently with LOCK TABLES resulted in deadlock. (Bug#45066: http://bugs.mysql.com/bug.php?id=45066) * The mysql_real_connect() C API function only attempted to connect to the first IP address returned for a hostname. This could be a problem if a hostname mapped to multiple IP address and the server was not bound to the first one returned. Now mysql_real_connect() attempts to connect to all IPv4 or IPv6 addresses that a domain name maps to. (Bug#45017: http://bugs.mysql.com/bug.php?id=45017) See also Bug#47757: http://bugs.mysql.com/bug.php?id=47757. * Some plugins configured as mandatory could be disabled at server startup. (Bug#44691: http://bugs.mysql.com/bug.php?id=44691) * InnoDB took a shared row lock when executing SELECT statements inside a stored function as a part of a transaction using REPEATABLE READ. This prevented other transactions from updating the row. (Bug#44613: http://bugs.mysql.com/bug.php?id=44613) * MySQL Server allowed the creation of a merge table based on views but crashed when attempts were made to read from that table. (Bug#44040: http://bugs.mysql.com/bug.php?id=44040) * A natural join of INFORMATION_SCHEMA tables could cause an assertion failure. (Bug#43834: http://bugs.mysql.com/bug.php?id=43834) * When used in conjunction with LOCK TABLES, FLUSH TABLE tbl_list waited for all tables with old versions to clear from the table definition list, rather than only the named tables. (Bug#43685: http://bugs.mysql.com/bug.php?id=43685) * HANDLER statements are now disallowed if a table lock has been acquired with LOCK TABLES. (Bug#43272: http://bugs.mysql.com/bug.php?id=43272) * In the embedded server, stack overflow checks for recursive stored procedure calls did not work and stack overflow could occur. (Bug#43201: http://bugs.mysql.com/bug.php?id=43201) * The IPv6 loopback address ::1 was interpeted as a hostname rather than a numeric IP address. In addition, the IPv6-enabled server on Windows interpeted the hostname localhost as ::1 only, which failed to match the default root@127.0.0.1 entry in the mysql.user privilege table. (Bug#43006: http://bugs.mysql.com/bug.php?id=43006) See also Bug#38247: http://bugs.mysql.com/bug.php?id=38247, Bug#45283: http://bugs.mysql.com/bug.php?id=45283, Bug#45584: http://bugs.mysql.com/bug.php?id=45584, Bug#45606: http://bugs.mysql.com/bug.php?id=45606. * The server could crash if an attempt to open a MERGE table child MyISAM table failed. (Bug#42862: http://bugs.mysql.com/bug.php?id=42862) * Comparison of TIME values could lose the sign of operands. (Bug#42664: http://bugs.mysql.com/bug.php?id=42664) * MAKETIME() could lose the sign of negative arguments. (Bug#42662: http://bugs.mysql.com/bug.php?id=42662) * SEC_TO_TIME() could lose the sign of negative arguments. (Bug#42661: http://bugs.mysql.com/bug.php?id=42661) * Due to work done for Bug#989: http://bugs.mysql.com/bug.php?id=989, FLUSH TABLES is disallowed when there is an active LOCK TABLES ... READ. This caused a problem with mysqlhotcopy, which used that sequence of statements. mysqlhotcopy now uses FLUSH TABLES tbl_list WITH READ LOCK to flush and lock tables. If mysqlhotcopy is used with a server older than MySQL 5.5.3 that does not support this statement, it has a new option --old_server that causes it to use the previous statement sequence. (Bug#42465: http://bugs.mysql.com/bug.php?id=42465) * Setting key_buffer_size to a negative value could lead to very large allocations. Now an error occurs. (Bug#42103: http://bugs.mysql.com/bug.php?id=42103) * An assertion failure could occur if OPTIMIZE TABLE was started on an InnoDB table and the table was altered to a different storage engine during the optimization operation. (Bug#42074: http://bugs.mysql.com/bug.php?id=42074) * The state of a thread for the embedded server was always displayed as Writing to net, which is incorrect because there is no network connection for the embedded server. (Bug#41971: http://bugs.mysql.com/bug.php?id=41971) * The patch for Bug#10374: http://bugs.mysql.com/bug.php?id=10374 broke named-pipe and shared-memory connections on Windows. (Bug#41860: http://bugs.mysql.com/bug.php?id=41860) * Purging the stored routine cache could take a long time and render the server unresponsive. (Bug#41804: http://bugs.mysql.com/bug.php?id=41804) * The CSV engine did not parse '\X' characters when they occurred in unquoted fields. (Bug#40814: http://bugs.mysql.com/bug.php?id=40814) * When archive tables were joined on their primary keys, a query returned no result if the optimizer chose to use this index. (Bug#40677: http://bugs.mysql.com/bug.php?id=40677) * mysqld_safe did not treat dashes and underscores as equivalent in option names. Thanks to Erik Ljungstrom for the patch to fix this bug. (Bug#40368: http://bugs.mysql.com/bug.php?id=40368) * SHOW CREATE VIEW returned invalid SQL if the definition contained a SELECT 'string' statement where the string was longer than the maximum length of a column name, due to the fact that this text was also used as an alias (in the AS clause). Because not all names retrieved from arbitrary SELECT statements can be used as view column names due to length and format restrictions, the server now checks the conformity of automatically generated column names and rewrites according to a predefined format any names that are not acceptable as view column names before storing the final view definition on disk. In such cases, the name is now rewritten as Name_exp_pos, where pos is the position of the column. To avoid this conversion scheme, define explicit, valid names for view columns using the column_list clause of the CREATE VIEW statement. As part of this fix, aliases are now generated only for top-level statements. (Bug#40277: http://bugs.mysql.com/bug.php?id=40277) * Threads were set to the Table lock state in such a way that use of this state by other threads to check for a lock wait was subject to a race condition. (Bug#39897: http://bugs.mysql.com/bug.php?id=39897) * Plugin shutdown could lead to an assertion failure caused by using an already destroyed mutex in the metadata locking subsystem. (Bug#39674: http://bugs.mysql.com/bug.php?id=39674) * Dropping a locked Maria table leads to an assertion failure. (Bug#39395: http://bugs.mysql.com/bug.php?id=39395) * Host name lookup failure could lead to a server crash. (Bug#39153: http://bugs.mysql.com/bug.php?id=39153) * flush_cache_records() did not correctly check for errors that should cause statement execution to stop, leading to a server crash. (Bug#39022: http://bugs.mysql.com/bug.php?id=39022) * Valgrind warnings that occurred for SHOW TABLE STATUS with InnoDB tables were silenced. (Bug#38479: http://bugs.mysql.com/bug.php?id=38479) * An IPv6-enabled MySQL server did not resolve the IP addresses of incoming connections correctly, with the result that a connection that attempted to match any privilege table entries using fully-qualified domain names for hostnames or hostnames using wildcards were dropped. (Bug#38247: http://bugs.mysql.com/bug.php?id=38247) See also Bug#43006: http://bugs.mysql.com/bug.php?id=43006, Bug#45283: http://bugs.mysql.com/bug.php?id=45283, Bug#45584: http://bugs.mysql.com/bug.php?id=45584, Bug#45606: http://bugs.mysql.com/bug.php?id=45606. * Concurrent execution of ALTER TABLE for InnoDB table and a transaction that tried to read and then update the table could result in a deadlock between table-level locks and InnoDB row locks, which was detected only after the innodb_lock_wait_timeout timeout occurred. (Bug#37346: http://bugs.mysql.com/bug.php?id=37346) * Previously, statements inside a stored program did not clear the warning list. For example, warnings or errors generated by statements within a trigger or stored function would be accumulated and added to the message list for the statement that activated the trigger or invoked the function, "polluting" the output of SHOW WARNINGS or SHOW ERRORS for the outer statement. Normally, messages for a statement that can generate messages replace messages from the previous such statement. The effect was that a statement could have a different effect on the message list depending on whether it executed inside or outside of a stored program. Now within a stored program, successive statements that can generate messages update the message list and replace messages from the previous such statement. Only messages from the last of these statements is copied to the message list for the outer statement. (Bug#36649: http://bugs.mysql.com/bug.php?id=36649) * myisampack --join did not create the destination table .frm file. (Bug#36573: http://bugs.mysql.com/bug.php?id=36573) * The parser incorrectly allowed MySQL error code 0 to be specified for a condition handler. (This is incorrect because the condition must be a failure condition and 0 indicates success.) (Bug#36510: http://bugs.mysql.com/bug.php?id=36510) * When parsing or formatting interval values of DAY_MICROSECOND type, fractional seconds were not handled correctly when more-significant fields were implied or omitted. (Bug#36466: http://bugs.mysql.com/bug.php?id=36466) * mysql_install_db failed if run as root and the root directory (/) was not writable. (Bug#36462: http://bugs.mysql.com/bug.php?id=36462) * mysql_stmt_prepare() did not reset the list of messages (those messages available via SHOW WARNINGS). (Bug#36004: http://bugs.mysql.com/bug.php?id=36004) * mysqlbinlog left temporary files on the disk after shutdown, leading to the pollution of the temporary directory, which eventually caused mysqlbinlog to fail. This caused problems in testing and other situations where mysqlbinlog might be invoked many times in a relatively short period of time. (Bug#35543: http://bugs.mysql.com/bug.php?id=35543) * When building MySQL when using a different target directory (for example using the VPATH environment variable), the build of the embedded readline component would fail. (Bug#35250: http://bugs.mysql.com/bug.php?id=35250) * String-valued system variables could be assigned literal values, but could not be assigned values using expressions. Now expressions are legal. (Bug#34883: http://bugs.mysql.com/bug.php?id=34883, Bug#46314: http://bugs.mysql.com/bug.php?id=46314) * The sql_mode system variable could be assigned the illegal value of '?'. (Bug#34834: http://bugs.mysql.com/bug.php?id=34834) * Some system variables could not be assigned the value DEFAULT to assign their default value. (Bug#34829: http://bugs.mysql.com/bug.php?id=34829, Bug#34878: http://bugs.mysql.com/bug.php?id=34878) * Compiling MySQL on FreeBSD would fail due to missing definitions for certain network constants. (Bug#34292: http://bugs.mysql.com/bug.php?id=34292) * Creation of a temporary BLOB or TEXT column could create a column with the wrong maximum length. (Bug#33969: http://bugs.mysql.com/bug.php?id=33969) * INSERT INTO ... VALUES(DEFAULT) failed to insert the correct value for ENUM columns. For MyISAM tables, an empty value was inserted. For CSV tables, the table became corrupt. (Bug#33717: http://bugs.mysql.com/bug.php?id=33717) * When read_only was enabled, the server incorrectly prevented data modifications to TEMPORARY tables belonging to transactional storage engines such as InnoDB. (Bug#33669: http://bugs.mysql.com/bug.php?id=33669) * Constant expressions in WHERE, HAVING, or ON clauses were not cached, but were evaluated for each row. This caused a slowdown of query execution, especially if constant user-defined functions or stored functions were used. (Bug#33546: http://bugs.mysql.com/bug.php?id=33546) * The parser accepted an INTO clause in nested SELECT statements, which is invalid because such statements must return their results to the outer context. (Bug#33204: http://bugs.mysql.com/bug.php?id=33204) * Killing a statement that invoked a stored function could return an incorrect error message indicating table corruption rather than that the statement had been interrupted. (Bug#32140: http://bugs.mysql.com/bug.php?id=32140) * Occurrence of an error within a stored routine did not always cause immediate statement termination. (Bug#31881: http://bugs.mysql.com/bug.php?id=31881) * For DROP FUNCTION db_name.func_name (that is, when the function name is qualified with the database name), the statement should apply only to a stored function named func_name in the given database. However, if a UDF with the same name existed, the statement dropped the UDF instead. (Bug#31767: http://bugs.mysql.com/bug.php?id=31767) * Concurrent statements using a stored function and DROP FUNCTION for that function could break statement-based replication. (Bug#30977: http://bugs.mysql.com/bug.php?id=30977) * mysqld sometimes miscalculated the number of digits required when storing a floating-point number in a CHAR column. This caused the value to be truncated, or (when using a debug build) caused the server to crash. (Bug#26788: http://bugs.mysql.com/bug.php?id=26788) See also Bug#12860: http://bugs.mysql.com/bug.php?id=12860. * ALTER TABLE could not be used to add columns to a table if the table had an index on a utf8 column with a TEXT data type. (Bug#26180: http://bugs.mysql.com/bug.php?id=26180) * If an operation had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (such as two distinct MyISAM tables), the triggers were unable to execute concurrently. In addition, INSERT and UPDATE statements for the InnoDB table were unable to run concurrently. (Bug#26141: http://bugs.mysql.com/bug.php?id=26141) * Some system variables displayed by SHOW VARIABLES could not be selected using SELECT @@{GLOBAL,SESSION}.var_name. (Bug#25430: http://bugs.mysql.com/bug.php?id=25430) * Statements to create, alter, or drop a view were not waiting for completion of statements that were using the view, which led to incorrect sequences of statements in the binary log when statement-based logging was enabled. (Bug#25144: http://bugs.mysql.com/bug.php?id=25144) * Previously, the server handled character data types for a stored routine parameter, local routine variable created with DECLARE, or stored function return value as follows: If the CHARACTER SET attribute was present, the COLLATE attribute was not supported, so the character set's default collation was used. (This includes use of BINARY, which in this context specifies the binary collation of the character set.) If there was no CHARACTER SET attribute, the database character set and its default collation were used. Now for character data types, if there is a CHARACTER SET attribute in the declaration, the specified character set and its default collation is used. If the COLLATE is also present, that collation is used rather than the default collation. If there is no CHARACTER SET attribute, the database character set and collation in effect at routine creation time are used. (The database character set and collation are given by the value of the character_set_database and collation_database system variables.) (Bug#24690: http://bugs.mysql.com/bug.php?id=24690) * Data truncated for column col_num at row row_num warnings were generated for some (constant) values that did not have too high precision. (Bug#24541: http://bugs.mysql.com/bug.php?id=24541) * A statement that caused a circular wait among statements did not return a deadlock error. Now the server detects deadlock and returns ER_LOCK_DEADLOCK. (Bug#22876: http://bugs.mysql.com/bug.php?id=22876) * Several data-modification statements were not being counted toward the MAX_UPDATES_PER_HOUR user resource limit. (Bug#21793: http://bugs.mysql.com/bug.php?id=21793) * When inserting an extraordinarly large value into a DOUBLE column, the value could be truncated in such a way that the new value cannot be reloaded manually or from the output of mysqldump. (Bug#21497: http://bugs.mysql.com/bug.php?id=21497) * The value of sql_slave_skip_counter was empty when displayed by SHOW VARIABLES or INFORMATION_SCHEMA.GLOBAL_VARIABLES. (Bug#20413: http://bugs.mysql.com/bug.php?id=20413, Bug#37187: http://bugs.mysql.com/bug.php?id=37187) * For INSERT DELAYED statements issued for a table while an ALTER TABLE operation on the table was in progress, the server could return a spurious Server shutdown in progress error. (Bug#18484: http://bugs.mysql.com/bug.php?id=18484) See also Bug#45949: http://bugs.mysql.com/bug.php?id=45949. * Delayed-insert threads were counted as connected but not as created, incorrectly leading to a Threads_connected value greater than the Threads_created value. (Bug#17954: http://bugs.mysql.com/bug.php?id=17954) * The character set was not being properly initialized for CAST() with a type such as CHAR(2) BINARY, which resulted in incorrect results or a server crash. (Bug#17903: http://bugs.mysql.com/bug.php?id=17903) * Stored procedure exception handlers were catching fatal errors (such as out of memory errors), which could cause execution not to stop to due a continue handler. Now fatal errors are not caught by exception handlers and a fatal error is returned to the client. (Bug#15192: http://bugs.mysql.com/bug.php?id=15192) * Zero-padding of exponent values was not the same across platforms. (Bug#12860: http://bugs.mysql.com/bug.php?id=12860) * For CREATE TABLE, the parser did not enforce that parentheses were present in a CHECK (expr) clause; now it does. The parser did not enforce that CONSTRAINT [symbol] without a following CHECK clause was illegal; now it does. (Bug#11714: http://bugs.mysql.com/bug.php?id=11714, Bug#35578: http://bugs.mysql.com/bug.php?id=35578, Bug#38696: http://bugs.mysql.com/bug.php?id=38696) * If a connection was waiting for a GET_LOCK() lock or a SLEEP() call, and the connection aborted, the server did not detect this and thus did not close the connection. This caused a waste of system resources allocated to dead connections. Now the server checks such a connection every five seconds to see whether it has been aborted. If so, the connection is killed (and any lock request is aborted). (Bug#10374: http://bugs.mysql.com/bug.php?id=10374) * perror did not work for errors described in the sql/share/errmsg.txt file. (Bug#10143: http://bugs.mysql.com/bug.php?id=10143) * The grammar for GROUP BY, when used with WITH CUBE or WITH ROLLUP, caused a conflict with the grammar for view definitions that included WITH CHECK OPTION. (Bug#9801: http://bugs.mysql.com/bug.php?id=9801) * For the DIV operator, incorrect results could occur for noninteger operands that exceed BIGINT range. Now, if either operand has a noninteger type, the operands are converted to DECIMAL and divided using DECIMAL arithmetic before converting the result to BIGINT. If the result exceeds BIGINT range, an error occurs. (Bug#8457: http://bugs.mysql.com/bug.php?id=8457) * Labels in stored routines did not work if the character set was not latin1. (Bug#7088: http://bugs.mysql.com/bug.php?id=7088) * Previously, for some Asian CJK character sets, the UPPER() and LOWER() functions worked only for basic Latin letters (A-Z, a-z). The affected character sets are ujis, sjis, gb2312, cp932, eucjpms, big5, euckr, and gbk. Now UPPER() and LOWER() perform case conversion correctly for all characters in these character sets, with the exception that if a character set contains a character in only one lettercase, conversion to the other lettercase cannot be done.
--
Daniel Fischer, MySQL Release Engineering
Oracle Corporation, http://oss.oracle.com/
Subject
Views
Written By
Posted
10143
April 13, 2010 11:13AM
Re: MySQL Server 5.5.3-m3 and MySQL Server 5.5.4-m3 have been released
3827
April 13, 2010 11:14AM
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.