MySQL 歷史舊版本 Page48

更新時間：2011-03-16
更新細節：

What's new in this version:

Bugs fixed:

- InnoDB Storage Engine: Raised the number of I/O requests that each AIO helper thread could process, from 32 to 256. The new limit applies to Linux and Unix platforms; the limit on Windows remains 32.
- InnoDB Storage Engine: InnoDB returned values for “rows examined” in the query plan that were higher than expected. NULL values were treated in an inconsistent way. The inaccurate statistics could trigger “false positives” in combination with the MAX_JOIN_SIZE setting, because the queries did not really examine as many rows as reported.
- 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.)
- 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. 
- DES_DECRYPT() could crash if the argument was not produced by DES_ENCRYPT(). 
- The server and client did not always properly negotiate authentication plugin names. 
- --autocommit=ON did not work (it set the global autocommit value to 0, not 1). 
- 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; 
- SHOW PRIVILEGES did not display a row for the PROXY privilege. 
- SHOW PROFILE could truncate source file names or fail to show function names. 
- DELETE or UPDATE statements could fail if they used DATE or DATETIME values with a year, month, or day part of zero. 
- 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. 
- Memory leaks detected by Valgrind, some of which could cause incorrect query results, were corrected. 
- The DEFAULT_CHARSET and DEFAULT_COLLATION CMake options did not work. 
- An OUTER JOIN query using WHERE column IS NULL could return an incorrect result. 
- Starting the server with the --defaults-file=file_name option, where the file name had no extension, caused a server crash. 
- Outer joins with an empty table could produce incorrect results. 
- In debug builds, SUBSTRING_INDEX(FORMAT(...), FORMAT(...)) could cause a server crash. 
- When mysqladmin was run with the --sleep and --count options, it went into an infinite loop executing the specified command. 
- 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. 
- Parsing nested regular expressions could lead to recursion resulting in a stack overflow crash. 
- 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. 
- The mysql client went into an infinite loop if the standard input was a directory. 
- Outer joins on a unique key could return incorrect results. 
- The expression const1 BETWEEN const2 AND field was optimized incorrectly and produced incorrect results. 
- 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. 
- On FreeBSD and OpenBSD, the server incorrectly checked the range of the system date, causing legal values to be rejected. 
- Sorting using ORDER BY AVG(DISTINCT decimal_col) caused a server crash or incorrect results. 
- 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. 
- 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.

更新時間：2011-03-16
更新細節：

What's new in this version:

Bugs fixed:

- InnoDB Storage Engine: Raised the number of I/O requests that each AIO helper thread could process, from 32 to 256. The new limit applies to Linux and Unix platforms; the limit on Windows remains 32.
- InnoDB Storage Engine: InnoDB returned values for “rows examined” in the query plan that were higher than expected. NULL values were treated in an inconsistent way. The inaccurate statistics could trigger “false positives” in combination with the MAX_JOIN_SIZE setting, because the queries did not really examine as many rows as reported.
- 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.)
- 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. 
- DES_DECRYPT() could crash if the argument was not produced by DES_ENCRYPT(). 
- The server and client did not always properly negotiate authentication plugin names. 
- --autocommit=ON did not work (it set the global autocommit value to 0, not 1). 
- 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; 
- SHOW PRIVILEGES did not display a row for the PROXY privilege. 
- SHOW PROFILE could truncate source file names or fail to show function names. 
- DELETE or UPDATE statements could fail if they used DATE or DATETIME values with a year, month, or day part of zero. 
- 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. 
- Memory leaks detected by Valgrind, some of which could cause incorrect query results, were corrected. 
- The DEFAULT_CHARSET and DEFAULT_COLLATION CMake options did not work. 
- An OUTER JOIN query using WHERE column IS NULL could return an incorrect result. 
- Starting the server with the --defaults-file=file_name option, where the file name had no extension, caused a server crash. 
- Outer joins with an empty table could produce incorrect results. 
- In debug builds, SUBSTRING_INDEX(FORMAT(...), FORMAT(...)) could cause a server crash. 
- When mysqladmin was run with the --sleep and --count options, it went into an infinite loop executing the specified command. 
- 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. 
- Parsing nested regular expressions could lead to recursion resulting in a stack overflow crash. 
- 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. 
- The mysql client went into an infinite loop if the standard input was a directory. 
- Outer joins on a unique key could return incorrect results. 
- The expression const1 BETWEEN const2 AND field was optimized incorrectly and produced incorrect results. 
- 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. 
- On FreeBSD and OpenBSD, the server incorrectly checked the range of the system date, causing legal values to be rejected. 
- Sorting using ORDER BY AVG(DISTINCT decimal_col) caused a server crash or incorrect results. 
- 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. 
- 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.

更新時間：2011-03-08
更新細節：

What's new in this version:

# Bugs fixed:

* InnoDB Storage Engine: InnoDB returned values for “rows examined” in the query plan that were higher than expected. NULL values were treated in an inconsistent way. The inaccurate statistics could trigger “false positives” in combination with the MAX_JOIN_SIZE setting, because the queries did not really examine as many rows as reported.
* Partitioning: Trying to use the same column more than once in the partitioning key when partitioning a table by KEY caused mysqld to crash. Such duplication of key columns is now expressly disallowed, and fails with an appropriate error.
* 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.)
* 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 wich 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.
* 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.
* DELETE or UPDATE statements could fail if they used DATE or DATETIME values with a year, month, or day part of zero.
* The ESCAPE clause for the LIKE operator allows only expressions that evaluate to a constant at execution time, but aggregrate functions were not being rejected.
* Memory leaks detected by Valgrind, some of which could cause incorrect query results, were corrected.
* mysqlslap failed to check for a NULL return from mysql_store_result() and crashed trying to process the result set.
* In debug builds, SUBSTRING_INDEX(FORMAT(...), FORMAT(...)) could cause a server crash.
* When mysqldadmin was run with the --sleep and --count options, it went into an infinite loop executing the specified command.
* 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.
* Parsing nested regular expressions could lead to recursion resulting in a stack overflow crash.
* The mysql client went into an infinite loop if the standard input was a directory.
* The expression const1 BETWEEN const2 AND field was optimized incorrectly and produced incorrect results.
* 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.
* On FreeBSD and OpenBSD, the server incorrectly checked the range of the system date, causing legal values to be rejected.
* 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.

更新時間：2011-02-10
更新細節：

What's new in this version:

# Bugs fixed:

* 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)
* 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)
See also Bug#57071.
* 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: When multiple InnoDB buffer pools were enabled, SHOW ENGINE INNODB commands displayed information about each one, but not summary information combining statistics for the entire buffer pool subsystem. Now, the aggregated information is displayed in the BUFFER POOL AND MEMORY section, and information about individual buffer pool instances is displayed in a new INDIVIDUAL BUFFER POOL INFO section. (Bug#58461)
* InnoDB Storage Engine: The command to create a debug build (cmake -DWITH_DEBUG ...) now automatically sets the InnoDB debugging flag UNIV_DEBUG on all platforms. Formerly, the UNIV_DEBUG flag might not be set for Windows platforms with Visual Studio and not on OS X with Xcode. (Bug#58279)
* InnoDB Storage Engine: In InnoDB status output, the value for I/O sum[] could be incorrect, displayed as a very large number. (Bug#57600)
* 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)
* InnoDB Storage Engine: When the lowercase_system_names variable was set to 2, InnoDB could fail to restore a mysqldump dump of a table with foreign key constraints involving case-sensitive names. (Bug#55222)
* InnoDB Storage Engine: The OPTIMIZE TABLE statement would reset the auto-increment counter for an InnoDB table. Now the auto-increment value is preserved across this operation. (Bug#18274)
* Partitioning: A failed ALTER TABLE ... TRUNCATE PARTITION statement was still written to the binary log. (Bug#58147)
* Partitioning: Failed ALTER TABLE ... PARTITION statements could cause memory leaks. (Bug#56380)
See also Bug#46949, Bug#56996.
* Replication: While an INSERT DELAYED statement with a single inserted value does not return any visible warnings, such a warning could be still written into the error log. (Bug#57666)
See also Bug#49567.
* Replication: When closing a session that used temporary tables, binary logging could sometimes fail with a spurious Failed to write the DROP statement for temporary tables to binary log. (Bug#57288)
* 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 System variables used with the binary log, and Section 5.1.6, “Server Status Variables”. (Bug#57275)
* Replication: By default, a value is generated for an AUTO_INCREMENT column by inserting either NULL or 0 into the column. Setting the NO_AUTO_VALUE_ON_ZERO server SQL mode suppresses this behavior for 0, so that it occurs only when NULL is inserted into the column.
This behavior is also followed on a replication slave (by the slave SQL thread) when applying events that have been logged on the master using the statement-based format. However, when applying events that had been logged using the row-based format, NO_AUTO_VALUE_ON_ZERO was ignored, which could lead to an assertion.
To fix this issue, the value of an AUTO_INCREMENT column is no longer generated when applying an event that was logged using the row-based row format, as this value is already contained in the changes applied on the slave. (Bug#56662)
* 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)
* Replication: The BINLOG statement modified the values of session variables, which could lead to problems with operations such a point-in-time recovery. One such case occurred when replaying a row-based binary log which relied on setting foreign_key_checks = OFF on the session level in order to create and populate a set of InnoDB tables having foreign key constraints. (Bug#54903)
* 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)
* Replication: Previously, when a statement failed with a different error on the slave than on the master, the slave SQL thread displayed a message containing:
- The error message for the master error code
- The master error code
- The error message for the slaves error code
- The slave error code
However, the slave has no information with which to fill in any print format specifiers for the master message, so it actually displayed the message format string. To make it clearer that the slave is not displaying the actual message as it appears on the master, the slave now indicates that the master part of the output is the message format, not the actual message. For example, previously the slave displayed information like this:
Error: Query caused different errors on master and slave. Error on master: 'Duplicate entry '%-.192s' for key %d' (1062), Error on slave: 'no error' (0). Default database: 'test'. Query: 'insert into t1 values(1),(2)' (expected different error codes on master and slave)
Now the slave displays this:
Error: Query caused different errors on master and slave. Error on master: message format='Duplicate entry '%-.192s' for key %d' error code=1062 ; Error on slave: actual message='no error', error code=0. Default database: 'test'. Query: 'insert into t1 values(1),(2)' (expected different error codes on master and slave) (Bug#46697)
* 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)
See also Bug#37148, Bug#40611, Bug#43929, Bug#51019.
* Comparisons of aggregate values with TIMESTAMP values were incorrect. (Bug#59330)
* For DIV expressions, assignment of the result to multiple variables could cause a server crash. (Bug#59241)
See also Bug#8457.
* MIN(year_col) could return an incorrect result in some cases. (Bug#59211)
* mysqlslap failed to check for a NULL return from mysql_store_result() and crashed trying to process the result set. (Bug#59109)
* 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)
* Configuring MySQL with -DWITHOUT_PERFSCHEMA_STORAGE_ENGINE=1 caused build failures. (Bug#58953)
* Several Valgrind warnings were fixed. (Bug#58948, Bug#59021)
* OPTIMIZE TABLE for an InnoDB table could raise an assertion if the operation failed because it had been killed. (Bug#58933)
* If max_allowed_packet was set larger than 16MB, the server failed to reject too-large packets with “Packet too large” errors. (Bug#58887)
* A NOT IN predicate with a subquery containing a HAVING clause could retrieve too many rows, when the subquery itself returned NULL. (Bug#58818)
* EXPLAIN could crash for queries that accessed two derived tables. (Bug#58730)
* On Solaris, the MySQL build failed if it was configured with debugging enabled. (Bug#58699)
* Issuing EXPLAIN EXTENDED for a query that would use condition pushdown could cause mysqld to crash. (Bug#58553)
* An assertion could be raised for queries for which the optimizer could choose between Index Merge range access or const ref access methods. (Bug#58456)
* If MySQL was built with Visual Studio Express, the project wixca was not built. (Bug#58411)
* EXPLAIN could crash for queries that used GROUP_CONCAT(). (Bug#58396)
* CMake polluted the source tree by writing installation-related temporary files there. (Bug#58372)
* Security context references in sp_head.cc were rewritten for improved DTrace compatibility. (Bug#58350)
* The ucs2 character set does not support characters outside the Basic Multilingual Plane (BMP), but converting a string containing such characters did not produce a conversion-failure warning. (Bug#58321)
* A Valgrind failure occurred in fn_format when called from archive_discover. (Bug#58205)
* CMake did not add LINK_LIBRARIES for MYSQL_ADD_PLUGIN for libmysqld. (Bug#58158)
* An assertion could be raised if the server was closing a session at the same time the session was being killed by another thread. (Bug#58136)
* Condition pushdown optimization could push down conditions with incorrect column references. (Bug#58134)
* Configuration with maintainer mode enabled resulted in errors when compiling with icc. (Bug#57991, Bug#58871)
* An ORDER BY clause was bound to the incorrect substatement when used in UNION context. (Bug#57986)
* The BIT_AND() function could return incorrect results when a join returned no matching rows. (Bug#57954)
* If the set of values aggregated with AVG(DISTINCT) contained a NULL value, the function result could be incorrect. (Bug#57932)
* In rare cases, LIKE expressions failed for an indexed column that used a collation containing contractions. (Bug#57737)
* Unnecessary subquery evaluation in contexts such as statement preparation or view creation could cause a server crash. (Bug#57703)
* View creation could produce Valgrind warnings. (Bug#57352)
* NULL geometry values could cause a crash in Item_func_spatial_collection::fix_length_and_dec. (Bug#57321)
* It was possible to compile mysqld with Performance Schema support but with a dummy atomic-operations implementation, which caused a server crash. This problem does not affect binary distributions. It is helpful as a safety measure for users who build MySQL from source. (Bug#56769)
* The cp1251 character set did not properly support the Euro sign (0x88). For example, converting a string containing this character to utf8 resulted in '?' rather than the utf8 Euro sign. (Bug#56639)
* Some unsigned system variables could be displayed with negative values. (Bug#55794)
* CREATE DATABASE and DROP DATABASE caused mysql --one-database to lose track of the statement-filtering context. (Bug#54899)
* An assertion could be raised during concurrent execution of DROP DATABASE and REPAIR TABLE if the drop deleted a table's .TMD file at the same time the repair tried to read details from the old file that was just removed.
A problem could also occur when DROP TABLE tried to remove all files belonging to a table at the same time REPAIR TABLE had just deleted the table's .TMD file. (Bug#54486)
* After compilation from source, all header files were installed in the same directory, even those that should be installed into subdirectories of the installation include directory. (Bug#51925)
* When mysqld printed crash dump information, it incorrectly indicated that some valid pointers were invalid. (Bug#51817)
* On Mac OS X, a configuration error caused the preference pane to fail. (Bug#51264)
* On FreeBSD, if mysqld was killed with a SIGHUP signal, it could corrupt InnoDB .ibd files. (Bug#51023)
* An assertion could be raised if –1 was inserted into an AUTO_INCREMENT column by a statement writing more than one row. (Bug#50619)
* If a client supplied a user name longer than the maximum 16 characters allowed for names stored in the MySQL grant tables, all characters were being considered significant. Historically, only the first 16 characters were used to check for a match; this behavior was restored. (Bug#49752)
* The my_seek() and my_tell() functions ignored the MY_WME flag when they returned an error, which could cause client programs to hang. (Bug#48451)
* During assignment of values to system variables, legality checks on the value range occurred too late, preventing proper error checking. (Bug#43233)
* On Solaris, time-related functions such as NOW() or SYSDATE() could return a constant value. (Bug#42054)
* If the remote server for a FEDERATED table could not be accessed, queries for the INFORMATION_SCHEMA.TABLES table failed. (Bug#35333)

更新時間：2011-02-08
更新細節：

What's new in this version:

# Bugs fixed:

* 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)
* 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)
See also Bug#57071.
* InnoDB Storage Engine: A compilation problem affected the InnoDB source code on NetBSD/sparc64. (Bug#59327)
See also Bug#53916.
* InnoDB Storage Engine: In InnoDB status output, the value for I/O sum[] could be incorrect, displayed as a very large number. (Bug#57600)
* 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)
* InnoDB Storage Engine: The OPTIMIZE TABLE statement would reset the auto-increment counter for an InnoDB table. Now the auto-increment value is preserved across this operation. (Bug#18274)
* Partitioning: Failed ALTER TABLE ... PARTITION statements could cause memory leaks. (Bug#56380)
See also Bug#46949, Bug#56996.
* Replication: When closing a session that used temporary tables, binary logging could sometimes fail with a spurious Failed to write the DROP statement for temporary tables to binary log. (Bug#57288)
* Replication: By default, a value is generated for an AUTO_INCREMENT column by inserting either NULL or 0 into the column. Setting the NO_AUTO_VALUE_ON_ZERO server SQL mode suppresses this behavior for 0, so that it occurs only when NULL is inserted into the column.
This behavior is also followed on a replication slave (by the slave SQL thread) when applying events that have been logged on the master using the statement-based format. However, when applying events that had been logged using the row-based format, NO_AUTO_VALUE_ON_ZERO was ignored, which could lead to an assertion.
To fix this issue, the value of an AUTO_INCREMENT column is no longer generated when applying an event that was logged using the row-based row format, as this value is already contained in the changes applied on the slave. (Bug#56662)
* Replication: The BINLOG statement modified the values of session variables, which could lead to problems with operations such a point-in-time recovery. One such case occurred when replaying a row-based binary log which relied on setting foreign_key_checks = OFF on the session level in order to create and populate a set of InnoDB tables having foreign key constraints. (Bug#54903)
* 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)
* Replication: Previously, when a statement failed with a different error on the slave than on the master, the slave SQL thread displayed a message containing:
- The error message for the master error code
- The master error code
- The error message for the slaves error code
- The slave error code
However, the slave has no information with which to fill in any print format specifiers for the master message, so it actually displayed the message format string. To make it clearer that the slave is not displaying the actual message as it appears on the master, the slave now indicates that the master part of the output is the message format, not the actual message. For example, previously the slave displayed information like this:
Error: Query caused different errors on master and slave. Error on master: 'Duplicate entry '%-.192s' for key %d' (1062), Error on slave: 'no error' (0). Default database: 'test'. Query: 'insert into t1 values(1),(2)' (expected different error codes on master and slave)
Now the slave displays this:
Error: Query caused different errors on master and slave. Error on master: message format='Duplicate entry '%-.192s' for key %d' error code=1062 ; Error on slave: actual message='no error', error code=0. Default database: 'test'. Query: 'insert into t1 values(1),(2)' (expected different error codes on master and slave) (Bug#46697)
* 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)
See also Bug#37148, Bug#40611, Bug#43929, Bug#51019.
* MIN(year_col) could return an incorrect result in some cases. (Bug#59211)
* If max_allowed_packet was set larger than 16MB, the server failed to reject too-large packets with “Packet too large” errors. (Bug#58887)
* Issuing EXPLAIN EXTENDED for a query that would use condition pushdown could cause mysqld to crash. (Bug#58553)
* EXPLAIN could crash for queries that used GROUP_CONCAT(). (Bug#58396)
* Configuration with maintainer mode enabled resulted in errors when compiling with icc. (Bug#57991, Bug#58871)
* Unnecessary subquery evaluation in contexts such as statement preparation or view creation could cause a server crash. (Bug#57703)
* View creation could produce Valgrind warnings. (Bug#57352)
* NULL geometry values could cause a crash in Item_func_spatial_collection::fix_length_and_dec. (Bug#57321)
* The cp1251 character set did not properly support the Euro sign (0x88). For example, converting a string containing this character to utf8 resulted in '?' rather than the utf8 Euro sign. (Bug#56639)
* Some unsigned system variables could be displayed with negative values. (Bug#55794)
* CREATE DATABASE and DROP DATABASE caused mysql --one-database to lose track of the statement-filtering context. (Bug#54899)
* An assertion could be raised during concurrent execution of DROP DATABASE and REPAIR TABLE if the drop deleted a table's .TMD file at the same time the repair tried to read details from the old file that was just removed.
A problem could also occur when DROP TABLE tried to remove all files belonging to a table at the same time REPAIR TABLE had just deleted the table's .TMD file. (Bug#54486)
* When mysqld printed crash dump information, it incorrectly indicated that some valid pointers were invalid. (Bug#51817)
* On FreeBSD, if mysqld was killed with a SIGHUP signal, it could corrupt InnoDB .ibd files. (Bug#51023)
* An assertion could be raised if –1 was inserted into an AUTO_INCREMENT column by a statement writing more than one row. (Bug#50619)
* If a client supplied a user name longer than the maximum 16 characters allowed for names stored in the MySQL grant tables, all characters were being considered significant. Historically, only the first 16 characters were used to check for a match; this behavior was restored. (Bug#49752)
* The my_seek() and my_tell() functions ignored the MY_WME flag when they returned an error, which could cause client programs to hang. (Bug#48451)
* During assignment of values to system variables, legality checks on the value range occurred too late, preventing proper error checking. (Bug#43233)
* On Solaris, time-related functions such as NOW() or SYSDATE() could return a constant value. (Bug#42054)
* If the remote server for a FEDERATED table could not be accessed, queries for the INFORMATION_SCHEMA.TABLES table failed. (Bug#35333)

更新時間：2010-12-15
更新細節：

What's new in this version:

# Functionality added or changed:

* Support for the IBMDB2I storage engine has been removed.
* The pstack library was nonfunctional and has been removed, along with the --with-pstack option for configure. The --enable-pstack option for mysqld is deprecated and will be removed in MySQL 5.5.

# Bugs fixed:

* Performance: InnoDB Storage Engine: Improved concurrency when several ANALYZE TABLE or SHOW TABLE STATUS statements are run simultaneously for InnoDB tables.
* 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.
* Partitioning: An INSERT ... ON DUPLICATE KEY UPDATE column = 0 statement on an AUTO_INCREMENT column caused the debug server to crash.
* Several compilation problems were fixed.
* Passing a string that was not null-terminated to UpdateXML() or ExtractValue() caused the server to fail with an assertion.
* Queries executed using the Index Merge access method and a temporary file could return incorrect results.
* The find_files() function used by SHOW statements performed redundant and unnecessary memory allocation.

更新時間：2010-11-19
更新細節：

What's new in this version:

# Bugs fixed:
- Replication: SET PASSWORD caused row-based replication to fail between a MySQL 5.1 master and a MySQL 5.5 slave.
* This fix makes it possible to replicate SET PASSWORD correctly, using row-based replication between a master running MySQL 5.1.53 or a later MySQL 5.1 release to a slave running MySQL 5.5.7 or a later MySQL 5.5 release. 
- Replication: An ALTER TABLE statement against a MyISAM table that altered a column without setting its size caused the binary log to become corrupted, leading to replication failure. 
- 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. 
- 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. 
- Replication: When a slave tried to execute a transaction larger than the slave's value for max_binlog_cache_size, it crashed. This was caused by an assertion that the server should roll back only the statement but not the entire transaction when the error ER_TRANS_CACHE_FULL occurred. However, the slave SQL thread always rolled back the entire transaction whenever any error occurred, regardless of the type of error. 
- 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. 
- Replication: Trying to read from a binary log containing a log event of an invalid type caused the slave to crash. 
- Replication: When replicating the mysql.tables_priv table, the Grantor column was not replicated, and was thus left empty on the slave. 
- Handling of host name lettercase in GRANT statements was inconsistent. 

更新時間：2010-11-02
更新細節：

What's new in this version:

# Bugs fixed:
- InnoDB Storage Engine: InnoDB incorrectly reported an error when a cascading foreign key constraint deleted more than 250 rows.
- InnoDB Storage Engine: A SELECT ... FOR UPDATE statement affecting a range of rows in an InnoDB table could cause a crash in the debug version of the server.
- InnoDB Storage Engine: Improved the performance of UPDATE operations on InnoDB tables, when only non-indexed columns are changed.
- InnoDB Storage Engine: The server could crash on shutdown, if started with --innodb-use-system-malloc=0. 
- InnoDB Storage Engine: Setting the PACK_KEYS=0 table option for an InnoDB table prevented new indexes from being added to the table. 
- InnoDB Storage Engine: Changed the locking mechanism for the InnoDB data dictionary during ROLLBACK operations, to improve concurrency for REPLACE statements. 
- InnoDB Storage Engine: InnoDB transactions could be incorrectly committed during recovery, rather than rolled back, if the server crashed and was restarted after performing ALTER TABLE...ADD PRIMARY KEY on an InnoDB table, or some other operation that involves copying the entire table. 
- Partitioning: Replication: Attempting to execute LOAD DATA on a partitioned MyISAM table while using statement-based logging mode caused the master to hang or crash. 
- Partitioning: Multi-table UPDATE statements involving a partitioned MyISAM table could cause this table to become corrupted. Not all tables affected by the UPDATE needed to be partitioned for this issue to be observed. 
- Partitioning: EXPLAIN PARTITIONS returned bad estimates for range queries on partitioned MyISAM tables. In addition, values in the rows column of EXPLAIN PARTITIONS output did not take partition pruning into account.
- Replication: Backticks used to enclose idenitfiers for savepoints were not preserved in the binary log, which could lead to replication failure when the identifier, stripped of backticks, could be misinterpreted, causing a syntax or other error.
* If a query specified a DATE or DATETIME value in a format different from 'YYYY-MM-DD HH:MM:SS', a greater-than-or-equal (>=) condition matched only greater-than values in an indexed TIMESTAMP column. 
* If there was an active SELECT statement, an error arising during trigger execution could cause a server crash. 
* With an UPDATE IGNORE statement including a subquery that was evaluated using a temporary table, an error transferring the data from the temporary was ignored, causing an assertion to be raised. 
* Row subqueries producing no rows were not handled as UNKNOWN values in row comparison expressions. 
* The max_length metadata value of MEDIUMBLOB types was reported as 1 byte greater than the correct value. 
* In some cases, when the left part of a NOT IN subquery predicate was a row and contained NULL values, the query result was incorrect. 
* For some queries, the optimizer produced incorrect results using the Index Merge access method with InnoDB tables. 
- EXPLAIN produced an incorrect rows value for queries evaluated using an index scan and that included LIMIT, GROUP BY, and ORDER BY on a computed column. 
- mysql_store_result() and mysql_use_result() are not for use with prepared statements and are not intended to be called following mysql_stmt_execute(), but failed to return an error when invoked that way. 
* A malformed packet sent by the server when the query cache was in use resulted in lost-connection errors. 
- CREATE TABLE failed if a column referred to in an index definition and foreign key definition was in different lettercases in the two definitions. 

更新時間：2010-09-27
更新細節：

What's new in this version:

# Bugs fixed:

* Incompatible Change: Replication: As of MySQL 5.5.6, handling of CREATE TABLE IF NOT EXISTS ... SELECT statements has been changed for the case that the destination table already exists:
- Previously, for CREATE TABLE IF NOT EXISTS ... SELECT, MySQL produced a warning that the table exists, but inserted the rows and wrote the statement to the binary log anyway. By contrast, CREATE TABLE ... SELECT (without IF NOT EXISTS) failed with an error, but MySQL inserted no rows and did not write the statement to the binary log.
- MySQL now handles both statements the same way when the destination table exists, in that neither statement inserts rows or is written to the binary log. The difference between them is that MySQL produces a warning when IF NOT EXISTS is present and an error when it is not.
- This change in handling of IF NOT EXISTS results in an incompatibility for statement-based replication from a MySQL 5.1 master with the original behavior and a MySQL 5.5 slave with the new behavior. Suppose that CREATE TABLE IF NOT EXISTS ... SELECT is executed on the master and the destination table exists. The result is that rows are inserted on the master but not on the slave. (Row-based replication does not have this problem.)
- To address this issue, statement-based binary logging for CREATE TABLE IF NOT EXISTS ... SELECT is changed in MySQL 5.1 as of 5.1.51:
- If the destination table does not exist, there is no change: The statement is logged as is.
- If the destination table does exist, the statement is logged as the equivalent pair of CREATE TABLE IF NOT EXISTS and INSERT ... SELECT statements. (If the SELECT in the original statement is preceded by IGNORE or REPLACE, the INSERT becomes INSERT IGNORE or REPLACE, respectively.)
- This change provides forward compatibility for statement-based replication from MySQL 5.1 to 5.5 because when the destination table exists, the rows will be inserted on both the master and slave. To take advantage of this compatibility measure, the 5.1 server must be at least 5.1.51 and the 5.5 server must be at least 5.5.6.To upgrade an existing 5.1-to-5.5 replication scenario, upgrade the master first to 5.1.51 or higher. Note that this differs from the usual replication upgrade advice of upgrading the slave first.A workaround for applications that wish to achieve the original effect (rows inserted regardless of whether the destination table exists) is to use CREATE TABLE IF NOT EXISTS and INSERT ... SELECT statements rather than CREATE TABLE IF NOT EXISTS ... SELECT statements.Along with the change just described, the following related change was made: Previously, if an existing view was named as the destination table for CREATE TABLE IF NOT EXISTS ... SELECT, rows were inserted into the underlying base table and the statement was written to the binary log. As of MySQL 5.1.51 and 5.5.6, nothing is inserted or logged. (Bug#47442, Bug#47132, Bug#48814, Bug#49494)
* Incompatible Change: Previously, if you flushed the logs using FLUSH LOGS or mysqladmin flush-logs and mysqld was writing the error log to a file (for example, if it was started with the --log-error option), it renamed the current log file with the suffix -old, then created a new empty log file. This had the problem that a second log-flushing operation thus caused the original error log file to be lost unless you saved it under a different name. For example, you could use the following commands to save the file: shell> mysqladmin flush-logs shell> mv host_name.err-old backup-directory To avoid the preceding file-loss problem, renaming no longer occurs. The server merely closes and reopens the log file. To rename the file, you can do so manually before flushing. Then flushing the logs reopens a new file with the original file name. For example, you can rename the file and create a new one using the following commands: shell> mv host_name.err host_name.err-old shell> mysqladmin flush-logs shell> mv host_name.err-old backup-directory (Bug#29751)
* Partitioning: When the storage engine used to create a partitioned table was disabled, attempting to drop the table caused the server to crash. (Bug#46086)
* If a view was named as the destination table for CREATE TABLE ... SELECT, the server produced a warning whether or not IF NOT EXISTS was used. Now it produces a warning only when IF NOT EXISTS is used, and an error otherwise. (Bug#55777)
* The CHECK TABLE command could cause a time-consuming verification of the InnoDB adaptive hash index memory structure. Now this extra checking is only performed in binaries built for debugging. (Bug#55716)
* After the fix for Bug#39653, the shortest available secondary index was used for full table scans. The primary clustered key was used only if no secondary index could be used. However, when the chosen secondary index includes all columns of the table being scanned, it is better to use the primary index because the amount of data to scan is the same but the primary index is clustered. This is now taken into account. (Bug#55656)
* (Bug#55627)
* The server was not checking for errors generated during the execution of Item::val_xxx() methods when copying data to a group, order, or distinct temp table's row. (Bug#55580)
* ORDER BY clauses that included user variable expressions could cause a debug assertion to be raised. (Bug#55565)
* Queries involving predicates of the form const NOT BETWEEN not_indexed_column AND indexed_column could return incorrect data due to incorrect handling by the range optimizer. (Bug#54802)
* MIN() or MAX() with a subquery argument could raise a debug assertion for debug builds or return incorrect data for nondebug builds. (Bug#54465)
* INFORMATION_SCHEMA plugins with no deinit() method resulted in a memory leak. (Bug#54253)
* INSERT IGNORE INTO ... SELECT statements could cause a debug assertion to be raised. (Bug#54106)
* The fix for Bug#30234 caused the server to reject the DELETE tbl_name.* ... Access compatibility syntax for multiple-table DELETE statements. (Bug#53034)
* Enumeration plugin variables were subject to a type casting error, causing inconsistent results between different platforms. (Bug#42144)
* A PKG install on Solaris put some files in incorrect locations. (Bug#31058)

更新時間：2010-08-19
更新細節：

What's new in this version:

# Bugs fixed:

* Important Change: Replication: The LOAD DATA INFILE statement is now considered unsafe for statement-based replication. When using statement-based logging mode, the statement now produces a warning; when using mixed-format logging, the statement is made using the row-based format. (Bug#34283)
* Partitioning: UPDATE and INSERT statements affecting partitioned tables performed poorly when using row-based replication. (Bug#52517)
* Partitioning: INSERT ON DUPLICATE KEY UPDATE statements performed poorly on tables having many partitions. This was because the handler function for reading a row from a specific index was not optimized in the partitioning handler. (Bug#52455)
* The server could crash on shutdown, if started with --innodb-use-system-malloc=0. (Bug#55581)
* GROUP BY operations used max_sort_length inconsistently. (Bug#55188)
* Building MySQL on Solaris 8 x86 failed when using Sun Studio due to gcc inline assembler code. (Bug#55061)
* In debug builds, an assertion could be raised when the server tried to send an OK packet to the client after having failed to detect errors during processing of the WHERE condition of an UPDATE statement. (Bug#54734)
* The database server could crash when renaming a table that had active transactions. (This issue only affected the database server when built for debugging.) (Bug#54453)
* The server could crash during the recovery phase of startup, if it previously crashed while inserting BLOB or other large columns that use off-page storage into an InnoDB table created with ROW_FORMAT=REDUNDANT or ROW_FORMAT=COMPACT. (Bug#54408)
* 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#54358)
* A client could supply data in chunks to a prepared statement parameter other than of type TEXT or BLOB using the mysql_stmt_send_long_data() C API function (or COM_STMT_SEND_LONG_DATA command). This led to a crash because other data types are not valid for long data. (Bug#54041)
* mysql_secure_installation did not properly identify local accounts and could incorrectly remove nonlocal root accounts. (Bug#54004)
* Transactions could be incorrectly committed during recovery, rather than rolled back, if the server crashed and was restarted after performing ALTER TABLE...ADD PRIMARY KEY on an InnoDB table, or some other operation that involves copying the entire table. (Bug#53756)
* Portability problems in SHOW STATUS could lead to incorrect results on some platforms. (Bug#53493)
* Builds of MySQL generated a large number of warnings. (Bug#53445)
* With lower_case_table_names set to a nonzero value, searches for table or database names in INFORMATION_SCHEMA tables could produce incorrect results. (Bug#53095)
* The ABI check for MySQL failed to compile with gcc 4.5. (Bug#52514)
* mysql_secure_installation sometimes failed to locate the mysql client. (Bug#52274)
* Reading a ucs2 data file with LOAD DATA INFILE was subject to three problems. 1) Incorrect parsing of the file as ucs2 data, resulting in incorrect length of the parsed string. This is fixed by truncating the invalid trailing bytes (incomplete multibyte characters) when reading from the file. 2) Reads from a proper ucs2 file did not recognize newline characters. This is fixed by first checking whether a byte is a newline (or any other special character) before reading it as a part of a multibyte character. 3) When using user variables to hold column data, the character set of the user variable was set incorrectly to the database charset. This is fixed by setting it to the character set specified in the LOAD DATA INFILE statement, if any. (Bug#51876)
* Searches in INFORMATION_SCHEMA tables for rows matching a nonexistent database produced an error instead of an empty query result. (Bug#49542)
* On FreeBSD, memory mapping for MERGE tables could fail if underlying tables were empty. (Bug#47139)
* The my_like_range_xxx() functions returned badly formed maximum strings for Asian character sets, which caused problems for storage engines. (Bug#45012)
* A debugging assertion could be raised after a write failure to a closed socket. (Bug#42496)
* An assertion failure occurred within yaSSL for very long keys. (Bug#29784) See also Bug#53463.