From: Hery Ramilison Date: April 11 2011 1:41pm Subject: MySQL Community Server 5.6.2 has been released (part 2 - bug fixes) List-Archive: http://lists.mysql.com/mysql/224799 Message-Id: <4DA30516.2030202@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear MySQL users, This is the list of bug fixes. For the functional enhancements, see part 1 of this mail: Bugs fixed: * Performance: InnoDB Storage Engine: An UPDATE statement for an InnoDB table could be slower than necessary if it changed a column covered by a prefix index, but did not change the prefix portion of the value. The fix improves performance for InnoDB 1.1 in MySQL 5.5 and higher, and the InnoDB Plugin for MySQL 5.1. (Bug #58912, Bug #11765900) * Incompatible Change: When auto_increment_increment is greater than one, values generated by a bulk insert that reaches the maximum column value could wrap around rather producing an overflow error. As a consequence of the fix, it is no longer possible for an auto-generated value to be equal to the maximum BIGINT UNSIGNED value. It is still possible to store that value manually, if the column can accept it. (Bug #39828, Bug #11749800) * Important Change: Partitioning: Date and time functions used as partitioning functions now have the types of their operands checked; use of a value of the wrong type is now disallowed in such cases. In addition, EXTRACT(WEEK FROM col), where col is a DATE or DATETIME column, is now disallowed altogether because its return value depends on the value of the default_week_format system variable. (Bug #54483, Bug #11761948) See also Bug #57071, Bug #11764255. * Important Change: Replication: The CHANGE MASTER TO statement required the value for RELAY_LOG_FILE to be an absolute path, while the MASTER_LOG_FILE path could be relative. The inconsistent behavior is resolved by permitting relative paths for RELAY_LOG_FILE, and by using the same basename for RELAY_LOG_FILE as for MASTER_LOG_FILE. For more information, see Section 12.5.2.1, "CHANGE MASTER TO Syntax." (Bug #12190, Bug #11745232) * Partitioning: InnoDB Storage Engine: The partitioning handler did not pass locking information to a table's storage engine handler. This caused high contention and thus slower performance when working with partitioned InnoDB tables. (Bug #59013) * InnoDB Storage Engine: The presence of a double quotation mark inside the COMMENT field for a column could prevent a foreign key constraint from being created properly. (Bug #59197, Bug #11766154) * InnoDB Storage Engine: It was not possible to query the information_schema.innodb_trx table while other connections were running queries involving BLOB types. (Bug #55397, Bug #11762763) * Partitioning: Failed ALTER TABLE ... PARTITION statements could cause memory leaks. (Bug #56380, Bug #11763641) See also Bug #46949, Bug #11755209, Bug #56996, Bug #11764187. * Replication: When using the statement-based logging format, INSERT ON DUPLICATE KEY UPDATE and INSERT IGNORE statements affecting transactional tables that did not fail were not written to the binary log if they did not insert any rows. (With statement-based logging, all successful statements should be logged, whether they do or do not cause any rows to be changed.) (Bug #59338, Bug #11766266) * Replication: Formerly, STOP SLAVE stopped the slave I/O thread first and then stopped the slave SQL thread; thus, it was possible for the I/O thread to stop after replicating only part of a transaction which the SQL thread was executing, in which case---if the transaction could not be rolled back safely---the SQL thread could hang. Now, STOP SLAVE stops the slave SQL thread first and then stops the I/O thread; this guarantees that the I/O thread can fetch any remaining events in the transaction that the SQL thread is executing, so that the SQL thread can finish the transaction if it cannot be rolled back safely. (Bug #58546, Bug #11765563) * Replication: mysqlbinlog printed USE statements to its output only when the default database changed between events. To illustrate how this could cause problems, suppose that a user issued the following sequence of statements: CREATE DATABASE mydb; USE mydb; CREATE TABLE mytable (column_definitions); DROP DATABASE mydb; CREATE DATABASE mydb; USE mydb; CREATE TABLE mytable (column_definitions); When played back using mysqlbinlog, the second CREATE TABLE statement failed with Error: No Database Selected because the second USE statement was not played back, due to the fact that a database other than mydb was never selected. This fix insures that mysqlbinlog outputs a USE statement whenever it reads one from the binary log. (Bug #50914, Bug #11758677) * Replication: The --help text for mysqlbinlog now indicates that the --verbose (-v) option outputs pseudo-SQL that is not necessarily valid SQL and cannot be guaranteed to work verbatim in MySQL clients. (Bug #47557, Bug #11755743) * An assertion was raised if an XA COMMIT was issued when an XA transaction had already encountered an error (such as a deadlock) that required the transaction to be rolled back. (Bug #59986, Bug #11766788) * On some systems, debug builds of comp_err.c could fail due to an uninitialized variable. (Bug #59906, Bug #11766729) * Attempting to create a spatial index on a CHAR column longer than 31 bytes led to an assertion failure if the server was compiled with safemutex support. (Bug #59888, Bug #11766714) * Aggregation followed by a subquery could produce an incorrect result. (Bug #59839, Bug #11766675) * The Performance Schema did not update status handler status variables, so SHOW STATUS LIKE '%handler%' produced undercounted values. (Bug #59799, Bug #11766645) * Internally, XOR items partially behaved like functions and partially as conditions. This resulted in inconsistent handling and crashes. The issue is fixed by consistently treating XOR items as functions. (Bug #59793, Bug #11766642) * An incorrect character set pointer passed to my_strtoll10_mb2() caused an assertion to be raised. (Bug #59648, Bug #11766519) * DES_DECRYPT() could crash if the argument was not produced by DES_ENCRYPT(). (Bug #59632, Bug #11766505) * The server and client did not always properly negotiate authentication plugin names. (Bug #59453, Bug #11766356) * --autocommit=ON did not work (it set the global autocommit value to 0, not 1). (Bug #59432, Bug #11766339) * mysqldump did not quote database names in ALTER DATABASE statements in its output, which could cause an error at reload time for database names containing a dash. (Bug #59398, Bug #11766310) * If filesort fell back to an ordinary sort/merge, it could fail to handle memory correctly. (Bug #59331, Bug #11766260) * Comparisons of aggregate values with TIMESTAMP values were incorrect. (Bug #59330, Bug #11766259) * The "greedy" query plan optimizer failed to consider the size of intermediate query results when calculating the cost of a query. This could result in slowly executing queries when there are much faster execution plans available. (Bug #59326, Bug #11766256) * A query of the following form returned an incorrect result, where the values for col_name in the result set were entirely replaced with NULL values: SELECT DISTINCT col_name ... ORDER BY col_name DESC; (Bug #59308, Bug #11766241) * The MYSQL_HOME environment variable was being ignored. (Bug #59280, Bug #11766219) * SHOW PRIVILEGES did not display a row for the PROXY privilege. (Bug #59275, Bug #11766216) * SHOW PROFILE could truncate source file names or fail to show function names. (Bug #59273, Bug #11766214) * For DIV expressions, assignment of the result to multiple variables could cause a server crash. (Bug #59241, Bug #11766191) See also Bug #8457, Bug #11745058. * MIN(year_col) could return an incorrect result in some cases. (Bug #59211, Bug #11766165) * With index condition pushdown enabled, a join could produce an extra row due to parts of the select condition for the second table in the join not being evaluated. (Bug #59186, Bug #11766144) * DELETE or UPDATE statements could fail if they used DATE or DATETIME values with a year, month, or day part of zero. (Bug #59173) * The ESCAPE clause for the LIKE operator allows only expressions that evaluate to a constant at execution time, but aggregate functions were not being rejected. (Bug #59149, Bug #11766110) * Valgrind warnings about uninitialized variables were corrected. (Bug #59145, Bug #11766106) * Memory leaks detected by Valgrind, some of which could cause incorrect query results, were corrected. (Bug #59110, Bug #11766075) * mysqlslap failed to check for a NULL return from mysql_store_result() and crashed trying to process the result set. (Bug #59109, Bug #11766074) * There was an erroneous restriction on file attributes for LOAD DATA INFILE. (Bug #59085, Bug #11766052) * SHOW CREATE TRIGGER failed if there was a temporary table with the same name as the trigger subject table. (Bug #58996, Bug #11765972) * The DEFAULT_CHARSET and DEFAULT_COLLATION CMake options did not work. (Bug #58991, Bug #11765967) * In a subquery, a UNION with no referenced tables (or only a reference to the virtual table dual) did not allow an ORDER BY clause. (Bug #58970, Bug #11765950) * OPTIMIZE TABLE for an InnoDB table could raise an assertion if the operation failed because it had been killed. (Bug #58933, Bug #11765920) * If max_allowed_packet was set larger than 16MB, the server failed to reject too-large packets with "Packet too large" errors. (Bug #58887, Bug #11765878) * With index condition pushdown enabled, incorrect results were returned for queries on MyISAM tables involving HAVING and LIMIT, when the column in the WHERE condition contained NULL. (Bug #58838, Bug #11765835) * An uninitialized variable for the index condition pushdown access method could result in a server crash or Valgrind warnings. (Bug #58837, Bug #11765834) * A NOT IN predicate with a subquery containing a HAVING clause could retrieve too many rows, when the subquery itself returned NULL. (Bug #58818, Bug #11765815) * Running a query against an InnoDB table twice, first with index condition pushdown enabled and then with it disabled, could produce different results. (Bug #58816, Bug #11765813) * An assertion was raised if a stored routine had a DELETE IGNORE statement that failed but due to the IGNORE had not reported any error. (Bug #58709, Bug #11765717) * WHERE conditions of the following forms were evaluated incorrectly and could return incorrect results: WHERE null-valued-const-expression NOT IN (subquery) WHERE null-valued-const-expression IN (subquery) IS UNKNOWN (Bug #58628, Bug #11765642) * Issuing EXPLAIN EXTENDED for a query that would use condition pushdown could cause mysqld to crash. (Bug #58553, Bug #11765570) * An OUTER JOIN query using WHERE column IS NULL could return an incorrect result. (Bug #58490, Bug #11765513) * Starting the server with the --defaults-file=file_name option, where the file name had no extension, caused a server crash. (Bug #58455, Bug #11765482) * Outer joins with an empty table could produce incorrect results. (Bug #58422, Bug #11765451) * In debug builds, SUBSTRING_INDEX(FORMAT(...), FORMAT(...)) could cause a server crash. (Bug #58371, Bug #11765406) * When mysqladmin was run with the --sleep and --count options, it went into an infinite loop executing the specified command. (Bug #58221, Bug #11765270) * Some string manipulating SQL functions use a shared string object intended to contain an immutable empty string. This object was used by the SQL function SUBSTRING_INDEX() to return an empty string when one argument was of the wrong datatype. If the string object was then modified by the SQL function INSERT(), undefined behavior ensued. (Bug #58165, Bug #11765225) * Condition pushdown optimization could push down conditions with incorrect column references. (Bug #58134, Bug #11765196) * injector::transaction did not have support for rollback. (Bug #58082, Bug #11765150) * Parsing nested regular expressions could lead to recursion resulting in a stack overflow crash. (Bug #58026, Bug #11765099) * The fix for Bug#25192 caused load_defaults() to add an argument separator to distinguish options loaded from configure files from those provided on the command line, whether or not the application needed it. (Bug #57953, Bug #11765041) See also Bug #11746296. * The mysql client went into an infinite loop if the standard input was a directory. (Bug #57450, Bug #11764598) * If a multiple-table update updated a row through two aliases and the first update physically moved the row, the second update failed to locate the row. This resulted in different errors depending on storage engine, although these errors did not accurately describe the problem: + MyISAM: Got error 134 from storage engine + InnoDB: Can't find record in 'tbl' For MyISAM, which is nontransactional, the update executed first was performed but the second was not. In addition, for two equal multiple-table update statements, one could succeed and the other fail depending on whether the record actually moved, which is inconsistent. Now such an update returns an error if it will update a table through multiple aliases, and perform an update that may physically more the row in at least one of these aliases. (Bug #57373, Bug #11764529, Bug #55385, Bug #11762751) * SHOW WARNINGS output following EXPLAIN EXTENDED could include unprintable characters. (Bug #57341, Bug #11764503) * Outer joins on a unique key could return incorrect results. (Bug #57034, Bug #11764219) * For a query that used a subquery that included GROUP BY inside a < ANY() construct, no rows were returned when there should have been. (Bug #56690, Bug #11763918) * Some RPM installation scripts used a hardcoded value for the data directory, which could result in a failed installation for users who have a nonstandard data directory location. The same was true for other configuration values such as the PID file name. (Bug #56581, Bug #11763817) * On FreeBSD and OpenBSD, the server incorrectly checked the range of the system date, causing legal values to be rejected. (Bug #55755, Bug #11763089) * If one connection locked the mysql.func table using either FLUSH TABLES WITH READ LOCK or LOCK TABLE mysql.func WRITE and a second connection tried to either create or drop a UDF function, a deadlock occurred when the first connection tried to use a UDF function. (Bug #53322, Bug #11760878) * DISTINCT aggregates on DECIMAL UNSIGNED fields could trigger an assertion. (Bug #52171, Bug #11759827) * On FreeBSD, if mysqld was killed with a SIGHUP signal, it could corrupt InnoDB .ibd files. (Bug #51023, Bug #11758773) * An assertion could be raised if -1 was inserted into an AUTO_INCREMENT column by a statement writing more than one row. (Bug #50619, Bug #11758417) * A query that contained an aggregate function but no GROUP BY clause was implicitly grouped. But implicitly grouped queries return zero or one row, so ordering does not make sense. (Bug #47853) * The parser failed to initialize some internal objects properly, which could cause a server crash in the cleanup phase after statement execution. (Bug #47511, Bug #11755703) * When CASE ... WHEN arguments had different character sets, 8-bit values could be referenced as utf16 or utf32 values, causing an assertion to be raised. (Bug #44793, Bug #11753363) * When using ExtractValue() or UpdateXML(), if the XML to be read contained an incomplete XML comment, MySQL read beyond the end of the XML string when processing, leading to a crash of the server. (Bug #44332, Bug #11752979) * Bitmap functions used in one thread could change bitmaps used by other threads, causing an assertion to be raised. (Bug #43152, Bug #11752069) * DATE_ADD() and DATE_SUB() return a string if the first argument is a string, but incorrectly returned a binary string. Now they return a character string with a collation of connection_collation. (Bug #31384, Bug #11747221) * Incompatible Change: Replication: The behavior of INSERT DELAYED statements when using statement-based replication has changed as follows: Previously, when using binlog_format=STATEMENT, a warning was issued in the client when executing INSERT DELAYED; now, no warning is issued in such cases. Previously, when using binlog_format=STATEMENT, INSERT DELAYED was logged as INSERT DELAYED; now, it is logged as an INSERT, without the DELAYED option. However, when binlog_format=STATEMENT, INSERT DELAYED continues to be executed as INSERT (without the DELAYED option). The behavior of INSERT DELAYED remains unchanged when using binlog_format=ROW: INSERT DELAYED generates no warnings, is executed as INSERT DELAYED, and is logged using the row-based format. This change also affects binlog_format=MIXED, because INSERT DELAYED is no longer considered unsafe. Now, when the logging format is MIXED, no switch to row-based logging occurs. This means that the statement is logged as a simple INSERT (that is, without the DELAYED option), using the statement-based logging format. (Bug #54579, Bug #11762035) See also Bug #56678, Bug #11763907, Bug #57666. This regression was introduced by Bug #39934, Bug #11749859. * Incompatible Change: Replication: When determining whether to replicate a CREATE DATABASE, DROP DATABASE, or ALTER DATABASE statement, database-level options now take precedence over any --replicate-wild-do-table options. In other words, when trying to replicate one of these statements, --replicate-wild-do-table options are now checked if and only if there are no database-level options that apply to the statement. (Bug #46110, Bug #11754498) * 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: o Waiting for global metadata lock is replaced by Waiting for global read lock. o 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. o 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. o There are two other new states, Waiting for trigger metadata lock and Waiting for event metadata lock. (Bug #57006, Bug #11764195, Bug #54673, Bug #11762116) * Incompatible Change: CREATE TABLE statements (including CREATE TABLE ... LIKE) are now prohibited whenever a LOCK TABLES statement is in effect. (Bug #42546, Bug #11751609) * InnoDB Storage Engine: Replication: If the master had innodb_file_per_table=OFF, innodb_file_format=Antelope (and innodb_strict_mode=OFF), or both, certain CREATE TABLE options, such as KEY_BLOCK_SIZE, were ignored. This could allow master to avoid raising ER_TOO_BIG_ROWSIZE errors. However, the ignored CREATE TABLE options were still written into the binary log, so that, if the slave had innodb_file_per_table=ON and innodb_file_format=Barracuda, it could encounter an ER_TOO_BIG_ROWSIZE error while executing the record from the log, causing the slave SQL thread to abort and replication to fail. In the case where the master was running MySQL 5.1 and the slave was MySQL 5.5 (or later), the failure occurred when both master and slave were running with default values for innodb_file_per_table and innodb_file_format. This could cause problems during upgrades. To address this issue, the default values for innodb_file_per_table and innodb_file_format are reverted to the MySQL 5.1 default values---that is, OFF and Antelope, respectively. (Bug #56318, Bug #11763590) * InnoDB Storage Engine: With binary logging enabled, InnoDB could halt during crash recovery with a message referring to a transaction ID of 0. (Bug #54901, Bug #11762323) * Replication: Due to changes made in MySQL 5.5.3, settings made in the binlog_cache_size and max_binlog_cache_size server system variables affected both the binary log statement cache (also introduced in that version) and the binary log transactional cache (formerly known simply as the binary log cache). This meant that the resources used as a result of setting either or both of these variables were double the amount expected. To rectify this problem, these variables now affect only the transactional cache. The fix for this issue also introduces two new system variables binlog_stmt_cache_size and max_binlog_stmt_cache_size, which affect only the binary log statement cache. In addition, the Binlog_cache_use status variable was incremented whenever either cache was used, and Binlog_cache_disk_use was incremented whenever the disk space from either cache was used, which caused problems with performance tuning of the statement and transactional caches, because it was not possible to determine which of these was being exceeded when attempting to troubleshoot excessive disk seeks and related problems. This issue is solved by changing the behavior of these two status variables such that they are incremented only in response to usage of the binary log transactional cache, as well as by introducing two new status variables Binlog_stmt_cache_use and Binlog_stmt_cache_disk_use, which are incremented only by usage of the binary log statement cache. For more information, see Section 15.1.3.4, "System variables used with the binary log," and Section 5.1.6, "Server Status Variables." (Bug #57275, Bug #11764443) * Replication: The Binlog_cache_use and Binlog_cache_disk_use status variables were incremented twice by a change to a table using a transactional storage engine. (Bug #56343, Bug #11763611) * 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, Bug #11763416) * Replication: When an error occurred in the generation of the name for a new binary log file, the error was logged but not shown to the user. (Bug #46166, Bug #11754544) See also Bug #37148, Bug #11748696, Bug #40611, Bug #11750196, Bug #43929, Bug# 11752675, Bug #51019, Bug #11758769. * Replication: When lower_case_table_names was set to 1 on the slave, but not on the master, names of databases in replicated statements were not converted, causing replication to fail on slaves using case-sensitive file systems. This occurred for both statement-based and row-based replication. In addition, when using row-based replication with lower_case_table_names set to 1 on the slave only, names of tables were also not converted, also causing replication failure on slaves using case-sensitive file systems. (Bug #37656) * A Valgrind failure occurred in fn_format when called from archive_discover. (Bug #58205, Bug #11765259) * Passing a string that was not null-terminated to UpdateXML() or ExtractValue() caused the server to fail with an assertion. (Bug #57279, Bug #11764447) * In bootstrap mode, the server could not execute statements longer than 10,000 characters. (Bug #55817, Bug #11763139) * NULL values were not grouped properly for some joins containing GROUP BY. (Bug #45267, Bug #11753766) * A HAVING clause could be lost if an index for ORDER BY was available, incorrectly permitting additional rows to be returned. (Bug #45227, Bug #11753730) * The optimizer could underestimate the memory required for column descriptors during join processing and cause memory corruption or a server crash. (Bug #42744, Bug #11751763) * The server returned incorrect results for WHERE ... OR ... GROUP BY queries against InnoDB tables. (Bug #37977, Bug #11749031) * An incorrectly checked XOR subquery optimization resulted in an assertion failure. (Bug #37899, Bug #11748998) * A query that could use one index to produce the desired ordering and another index for range access with index condition pushdown could cause a server crash. (Bug #37851, Bug #11748981) * With index condition pushdown enabled, InnoDB could crash due to a mismatch between what pushdown code expected to be in a record versus what was actually there. (Bug #36981, Bug #11748647) * The range optimizer ignored conditions on inner tables in semi-join IN subqueries, causing the optimizer to miss good query execution plans. (Bug #35674, Bug #11748263) * A server crash or memory overrun could occur with a dependent subquery and joins. (Bug #34799, Bug #11748009) * Selecting from a view that referenced the same table in the FROM clause and an IN clause caused a server crash. (Bug #33245) * Deeply nested subqueries could cause stack overflow or a server crash. (Bug #32680, Bug #11747503) * The server crashed on optimization of queries that compared an indexed DECIMAL column with a string value. (Bug #32262, Bug #11747426) * The server crashed on optimizations that used the range checked for each record access method. (Bug #32229, Bug #11747417) * If the optimizer used a Multi-Range Read access method for index lookups, incorrect results could occur for rows that contained any of the BLOB or TEXT data types. (Bug #30622, Bug #11747076) * Compared to MySQL 5.1, the optimizer failed to use join buffering for certain queries, resulting in slower performance for those queries. (Bug #30363, Bug #11747028) * For Multi-Range Read scans used to resolve LIMIT queries, failure to close the scan caused file descriptor leaks for MyISAM tables. (Bug #30221, Bug #11746994) * SHOW CREATE DATABASE did not account for the value of the lower_case_table_names system variable. (Bug #21317, Bug #11745926) * InnoDB Storage Engine: The server could crash on shutdown, if started with --innodb-use-system-malloc=0. (Bug #55581, Bug #11762927) * Replication: The unused and deprecated server options --init-rpl-role and --rpl-recovery-rank, as well as the unused and deprecated status variable Rpl_status, have been removed. (Bug #54649, Bug #11762095) See also Bug #34437, Bug #11747900, Bug #34635, Bug #11747961. * Replication: The flag stating whether a user value was signed or unsigned (unsigned_flag) could sometimes change between the time that the user value was recorded for logging purposes and the time that the value was actually written to the binary log, which could lead to inconsistency. Now unsigned_flag is copied when the user variable value is copied, and the copy of unsigned_flag is then used for logging. (Bug #51426, Bug #11759138) See also Bug #49562, Bug #11757508. * The embedded server could crash when determining which directories to search for option files. (Bug #55062, Bug #11762465) * Performance Schema code was subject to a buffer overflow. (Bug #53363) * On Windows, an IPv6 connection to the server could not be made using an IPv4 address or host name. (Bug #52381, Bug #11760016) * Subquery execution for EXPLAIN could be done incorrectly and raise an assertion. (Bug #52317, Bug #11759957) * There was a mixup between GROUP BY and ORDER BY concerning which indexes should be considered or permitted during query optimization. (Bug #52081, Bug #11759746) * On Windows, the my_rename() function failed to check whether the source file existed. (Bug #51861, Bug #11759540) * The ref column of EXPLAIN output for subquery lines could be missing information. (Bug #50257, Bug #11758106) * Passwords for CREATE USER statements were written to the binary log in plaintext rather than in ciphertext. (Bug #50172) * The BLACKHOLE storage engine failed to load on Solaris and OpenSolaris if DTrace probes had been enabled. (Bug #47748, Bug #11755909) * Some error messages included a literal mysql database name rather than a parameter for the database name. (Bug #46792, Bug #11755079) * In the ER_TABLEACCESS_DENIED_ERROR error message, the command name parameter could be truncated. (Bug #45355, Bug #11753840) * On Windows, mysqlslap crashed for attempts to connect using shared memory. (Bug #31173, Bug #11747181) * To forestall the occurrence of possible relocation errors in the future, libmysys, libmystrings, and libdbug have been changed from normal libraries to "noinst" libtool helper libraries, and are no longer installed as separate libraries. (Bug #29791, Bug #11746931) * A suboptimal query execution plan could be chosen when there were several possible range and ref accesses. Now preference is given to the keys that match the most parts and choosing the best one among them. (Bug #26106, Bug #11746406) * Searches for data on a partial index for a column using the UTF8 character set would fail. (Bug #24858) * For queries with GROUP BY, FORCE INDEX was not ignored as it should have been when it would result in a more expensive query execution plan. (Bug #18144, Bug #11745649) Hery Ramilison MySQL/ORACLE Release Engineering Team