MySQL 5.1.21-beta がリリースされました。
http://dev.mysql.com/downloads/

5.1になってから一時的にログ出力先のデフォルトがテーブルになっていましたが、このバージョンからまた（5.0までと同様）ファイルへの出力がデフォルトになりました。

その他多くの修正がなされています。
詳しくはチェンジログをご覧ください。


----
以下チェンジログ


■機能の追加と変更(5.1.21)：

- Incompatible change: In MySQL 5.1.6, when log tables were implemented, the default log destination for the general query and slow query log was TABLE. This default has been changed to FILE, which is compatible with MySQL 5.0, but incompatible with earlier releases of MySQL 5.1 from 5.1.6 to 5.1.20. If you are upgrading from MySQL 5.0 to this release, no logging option changes should be necessary. However, if you are upgrading from 5.1.6 through 5.1.20 to this release and were using TABLE logging, use the --log-output=TABLE option explicitly to preserve your server's table-logging behavior. (Bug#29993: http://bugs.mysql.com/29993)

- The --syslog option that was introduced in 5.1.20 for mysqld_safe (to send error output to syslog) did not work correctly: Error output was buffered and not logged immediately. This has been corrected. In addition, some feature changes were made:
+ Important: The default mysqld_safe logging behavior now is --skip-syslog rather than --syslog, which is compatible with the default behavior of writing an error log file for releases prior to 5.1.20.
+ A new option, --syslog-tag=tag, modifies the default tags written by mysqld_safe and mysqld to syslog to be mysqld_safe-tag and mysqld-tag rather than the default tags of mysqld_safe and mysqld. (Bug#29992: http://bugs.mysql.com/29992)

- Several programs now accept --debug-check and --debug-info options: mysql, mysqladmin, mysqlbinlog, mysqlcheck, mysqldump, mysqlimport, mysqlshow, mysqlslap, mysqltest, mysql_upgrade. (Note: mysql and mysqltest already accepted --debug-info.) --debug-check prints debugging information at program exit. --debug-info is similar but also prints memory and CPU usage statistics. This patch also corrects a problem for mysql that --debug-info did not display statistics at exit time. (Bug#30127: http://bugs.mysql.com/30127)

- Transaction support in the FEDERATED storage engine has been disabled due to issues with multiple active transactions and sessions on the same FEDERATED table. (Bug#29875: http://bugs.mysql.com/29875)

- Previously, prepared statements processed using PREPARE and EXECUTE were not subject to caching in the query cache if they contained any ? parameter markers. This limitation has been lifted. (Bug#29318: http://bugs.mysql.com/29318)

- Replication between master and slaves now supports different column numbers within a table on both master and slave. The rules for replication where the table definitions are different has also changed. This supercedes the functionality for replication from the master table to a slave table with more columns that was added in MySQL 5.1.12. For more information, see Section 15.3.1.19, "Replication with Fewer Columns on the Slave."

- The SQL thread on a slave now is always allowed to enter InnoDB even if this would exceed the limit imposed by the innodb_thread_concurrency system variable. In cases of high load on the slave server (when innodb_thread_concurrency is reached), this change helps the slave stay more up to date with the master; in the previous behavior, the SQL thread was competing for resources with all client threads active on the slave server. (Bug#25078: http://bugs.mysql.com/25078)

■バグ修正(5.1.21)：

- Incompatible change: Several issues were identified for stored programs (stored functions and procedures, triggers, and events) and views containing non-ASCII symbols. These issues involved conversion errors due to incomplete character set information when translating these objects to and from stored format, such as:
+ Parsing the original object definition so that it can be stored.
+ Compiling the stored definition into executable form when the object is invoked.
+ Retrieval of object definitions from INFORMATION_SCHEMA tables.
+ Displaying the object definition in SHOW statements. This issue also affected mysqldump, which uses SHOW. The fix for the problems is to store character set information from the object creation context so that this information is available when the object needs to be used later. The context includes the client character set, the connection character set and collation, and the collation of the database with which the object is associated. As a result of the patch, several tables have new columns:
+ In the mysql database, the proc and event tables now have these columns: character_set_client, collation_connection, db_collation, body_utf8.
+ In INFORMATION_SCHEMA, the VIEWS table now has these columns: CHARACTER_SET_CLIENT, COLLATION_CONNECTION. The ROUTINES, TRIGGERS, and EVENT tables now have these columns: CHARACTER_SET_CLIENT, COLLATION_CONNECTION, DATABASE_COLLATION. These columns store the session values of the character_set_client and collation_connection system variables, and the collation of the database with which the object is associated. The values are those in effect at object creation time. (The saved database collation is not the value of the collation_database system variable, which applies to the default database; the database that contains the object is not necessarily the default database.) Several SHOW statements now display additional columns corresponding to the new table columns.
These statements are: SHOW CREATE EVENT, SHOW CREATE FUNCTION, SHOW CREATE PROCEDURE, SHOW CREATE VIEW, SHOW EVENTS, SHOW FUNCTION STATUS, SHOW PROCEDURE STATUS, SHOW TRIGGERS. A new statement, SHOW CREATE TRIGGER is introduced and is used by mysqldump for producing CREATE TRIGGER statements. (Bug#11986: http://bugs.mysql.com/11986, Bug#16291: http://bugs.mysql.com/16291, Bug#19443: http://bugs.mysql.com/19443, Bug#21249: http://bugs.mysql.com/21249, Bug#25212: http://bugs.mysql.com/25212, Bug#25221: http://bugs.mysql.com/25221, Bug#30027: http://bugs.mysql.com/30027) Subsequent to the patch just described, it was discovered that the patch broke mysql_upgrade; this has been corrected. (Bug#30029: http://bugs.mysql.com/30029) Important: To avoid warnings from the server about the use of old definitions from any release prior to 5.1.21, you should dump stored programs and views with mysqldump after upgrading to 5.1.21, and then reload them to recreate them with new definitions. Invoke mysqldump with a --default-character-set option that names the non-ASCII character set that was used for the definitions when the objects were originally defined.

- NDB Cluster: The server would not compile with NDB support on AIX 5.2. (Bug#10776: http://bugs.mysql.com/10776)

- NDB Cluster (Replication): Inconsistencies could occur between the master and the slave when replicating Disk Data tables. (Bug#19259: http://bugs.mysql.com/19259)

- NDB Cluster (Replication): mysqld would segfault on startup when the NDB storage engine was enabled and the default character set was a strictly multi-byte character set such as UCS2. (Bug#27404: http://bugs.mysql.com/27404) This issue does not apply to character sets that can contain single-byte characters in addition to multi-byte characters such as UTF-8. Additional issues remain with regard to the use of multi-byte character sets in MySQL Cluster Replication; see Section 16.10.3, "Known Issues in MySQL Cluster Replication," for more information.

- NDB Cluster: Warnings and errors generated by ndb_config --config-file=file were sent to stdout rather than stderr. (Bug#25941: http://bugs.mysql.com/25941)

- NDB Cluster (Disk Data): Performing Disk Data schema operations during a node restart could cause forced shutdowns of other data nodes. (Bug#29501: http://bugs.mysql.com/29501)

- NDB Cluster (Disk Data): Disk data meta-information that existed in ndbd might not be visible to mysqld. (Bug#28720: http://bugs.mysql.com/28720)

- NDB Cluster (Disk Data): The number of free extents was incorrectly reported for some tablespaces. (Bug#28642: http://bugs.mysql.com/28642)

- NDB Cluster (Cluster Replication): When executing a statement where binlog_format=statement, the result of the statement was logged both as a statement and as rows. (Bug#29222: http://bugs.mysql.com/29222)

- NDB Cluster: Replica redo logs were inconsistently handled during a system restart. (Bug#29354: http://bugs.mysql.com/29354)

- NDB Cluster: When restarting a data node, queries could hang during that node's start phase 5, and only continue once the node entered phase 6. (Bug#29364: http://bugs.mysql.com/29364)

- NDB Cluster: When a node failed to respond to a COPY_GCI signal as part of a global checkpoint, the master node was killed instead instead of the node that actually failed. (Bug#29331: http://bugs.mysql.com/29331)

- NDB Cluster: An invalid comparison made during REDO validation that could lead to an Error while reading REDO log condition. (Bug#29118: http://bugs.mysql.com/29118)

- NDB Cluster: The wrong data pages were sometimes invalidated following a global checkpoint. (Bug#29067: http://bugs.mysql.com/29067)

- NDB Cluster: If at least 2 files were involved in REDO invalidation, then file 0 of page 0 was not updated and so pointed to an invalid part of the redo log. (Bug#29057: http://bugs.mysql.com/29057)

- The server acquired a global mutex for temporary tables, although such tables are thread-specific. This affected performance by blocking other threads. (Bug#27062: http://bugs.mysql.com/27062)

- INSERT DELAYED statements on a master server are replicated as non-DELAYED inserts on slaves (which is normal, to preserve serialization), but the inserts on the slave did not use concurrent inserts. Now INSERT DELAYED on a slave is converted to a concurrent insert when possible, and to a normal insert otherwise. (Bug#29152: http://bugs.mysql.com/29152)

- If one thread was performing concurrent inserts, other threads reading from the same table using equality key searches could see the index values for new rows before the data values had been written, leading to reports of table corruption. (Bug#29838: http://bugs.mysql.com/29838)

- On Windows, client libraries lacked symbols required for linking. (Bug#30118: http://bugs.mysql.com/30118)

- On Windows, the CMake build process did not produce the embedded server library or related binaries. (Bug#29903: http://bugs.mysql.com/29903)

- SESSION_USER() returned garbage data (rather than the correct value of the empty string) when executed by a slave SQL thread. (Bug#29878: http://bugs.mysql.com/29878)

- For the SHOW TABLE TYPES statement, the server sent incorrect output to clients, possibly causing them to crash. (Bug#30036: http://bugs.mysql.com/30036)

- Coercion of ASCII values to character sets that are a superset of ASCII sometimes was not done, resulting in illegal mix of collations errors. These cases now are resolved using repertoire, a new string expression attribute (see Section 9.6, "String Repertoire"). (Bug#28875: http://bugs.mysql.com/28875)

- REPAIR TABLE ... USE_FRM could corrupt tables. (Bug#29980: http://bugs.mysql.com/29980)

- FEDERATED tables had an artificially low maximum of key length. (Bug#26909: http://bugs.mysql.com/26909)

- In some cases, INSERT INTO ... SELECT ... GROUP BY could insert rows even if the SELECT by itself produced an empty result. (Bug#29717: http://bugs.mysql.com/29717)

- In a stored function or trigger, when InnoDB detected deadlock, it attempted rollback and displayed an incorrect error message (Explicit or implicit commit is not allowed in stored function or trigger). Now InnoDB returns an error under these conditions and does not attempt rollback. Rollback is handled outside of InnoDB above the function/trigger level. (Bug#24989: http://bugs.mysql.com/24989)

- --myisam-recover="" (empty option value) did not disable MyISAM recovery. (Bug#29856: http://bugs.mysql.com/29856)

- Very long prepared statements in stored procedures could cause a server crash. (Bug#29856: http://bugs.mysql.com/29856)

- Index creation could fail due to truncation of key values to the maximum key length rather than to a mulitiple of the maximum character length. (Bug#28125: http://bugs.mysql.com/28125)

- mysql_setpermission tried to grant global-only privileges at the database level. (Bug#14618: http://bugs.mysql.com/14618)

- An error that happened inside INSERT, UPDATE, or DELETE statements performed from within a stored function or trigger could cause inconsistency between master and slave servers. (Bug#27417: http://bugs.mysql.com/27417)

- An assertion failure occurred within yaSSL for very long keys. (Bug#29784: http://bugs.mysql.com/29784)

- Repeatedly accessing a view in a stored procedure (for example, in a loop) caused a small amount of memory to be allocated per access. Although this memory is deallocated on disconnect, it could be a problem for a long running stored procedures that make repeated access of views. (Bug#29834: http://bugs.mysql.com/29834)

- The IS_UPDATABLE column in the INFORMATION_SCHEMA.VIEWS table was not always set correctly. (Bug#30020: http://bugs.mysql.com/30020)

- A slave running with --log-slave-updates would fail to write INSERT DELAY IGNORE statements to its binary log, resulting in different binary log contents on the master and slave. (Bug#29571: http://bugs.mysql.com/29571)

- InnoDB could crash if the server was shut down while innodb_table_monitor was running. (Bug#28254: http://bugs.mysql.com/28254)

- If MySQL/InnoDB crashed very quickly after starting up, it would not force a checkpoint. In this case, InnoDB would skip crash recovery at next startup, and the database would become corrupt. Fix: If the redo log scan at InnoDB startup goes past the last checkpoint, force crash recovery. (Bug#23710: http://bugs.mysql.com/23710)

- Certain statements with unions, subqueries, and joins could result in huge memory consumption. (Bug#29582: http://bugs.mysql.com/29582)

- SHOW statements were being written to the slow query log that should not have been. (Bug#30000: http://bugs.mysql.com/30000)

- Use of local variables with non-ASCII names in stored procedures crashed the server. (Bug#30120: http://bugs.mysql.com/30120)

- INSERT ... VALUES(CONNECTION_ID(), ...) statements were written to the binary log in such a way that they could not be properly restored. (Bug#29928: http://bugs.mysql.com/29928)

- Prepared statements containing CONNECTION_ID() could be written improperly to the binary log. (Bug#30200: http://bugs.mysql.com/30200)

- mysql_install_db could fail to find script files that it needs. (Bug#28585: http://bugs.mysql.com/28585)

- On Windows, executables did not include Vista manifests. (Bug#24732: http://bugs.mysql.com/24732)

- A maximum of 4TB InnoDB free space was reported by SHOW TABLE STATUS, which is incorrect on systems with more than 4TB space. (Bug#29097: http://bugs.mysql.com/29097)

- On Windows, the server used 10MB of memory for each connection thread, resulting in memory exhaustion. Now each thread uses 1MB. (Bug#20815: http://bugs.mysql.com/20815)

- Dropping a temporary InnoDB table that had been locked with LOCK TABLES caused a server crash. (Bug#24918: http://bugs.mysql.com/24918)

- Log table locking was redesigned, eliminating several lock-related problems:
+ Truncating mysql.slow_log in a stored procedure after use of a cursor caused the thread to lock. (Bug#17876: http://bugs.mysql.com/17876)
+ Flushing a log table resulted in warnings. (Bug#23044: http://bugs.mysql.com/23044)
+ The server would hang when performing concurrent ALTER TABLE or TRUNCATE TABLE statements against the log tables. (Bug#25422: http://bugs.mysql.com/25422)
+ Changing the value of the general_log system variable while a global read lock was in place resulted in deadlock. (Bug#29129: http://bugs.mysql.com/29129)

- LOCK TABLES did not pre-lock tables used in triggers of the locked tables. Unexpected locking behavior and statement failures similar to failed: 1100: Table 'xx' was not locked with LOCK TABLES could result. (Bug#29929: http://bugs.mysql.com/29929)

- Creating an event to be executed at a time close to the end of the allowed range (2038-01-19 03:14:07 UTC) would cause the server to crash. (Bug#28641: http://bugs.mysql.com/28641)

- On Windows, Instance Manager would crash if an instance object failed to initialize during startup. This could happen if an incorrect mysqld path was supplied in the configuration file. (Bug#28012: http://bugs.mysql.com/28012)

- Instance Manager had a race condition when it received a shutdown request while a guarded mysqld instance was starting such that it could fail to stop the mysqld instance. (Bug#28030: http://bugs.mysql.com/28030)

- Fast ALTER TABLE (that works without rebuilding the table) acquired duplicate locks in the storage engine. In MyISAM, if ALTER TABLE was issued under LOCK TABLE, it caused all data inserted after LOCK TABLE to disappear. (Bug#28838: http://bugs.mysql.com/28838)

- After the first read of a TEMPORARY table, CHECK TABLE could report the table as being corrupt. (Bug#26325: http://bugs.mysql.com/26325)

- The server was blocked from opening other tables while the FEDERATED engine was attempting to open a remote table. Now the server does not check the correctness of a FEDERATED table at CREATE TABLE time, but waits until the table actually is accessed. (Bug#25679: http://bugs.mysql.com/25679)

- On Mac OS X, shared-library installation pathnames were incorrect. (Bug#28544: http://bugs.mysql.com/28544)

- For MyISAM tables on Windows, INSERT, DELETE, or UPDATE followed by ALTER TABLE within LOCK TABLES could cause table corruption. (Bug#29957: http://bugs.mysql.com/29957)

- When determining which transaction to kill after deadlock has been detected, InnoDB now adds the number of locks to a transaction's weight, and avoids killing transactions that mave modified non-transactional tables. This should reduce the likelihood of killing long-running transactions containing SELECT ... FOR UPDATE or INSERT/REPLACE INTO ... SELECT statements, and of causing partial updates if the target is a MyISAM table. (Bug#21293: http://bugs.mysql.com/21293)

- When using a FEDERATED table, the value of last_insert_id() would not correctly update the C API interface, which would affect the autogenerated ID returned both through the C API and the MySQL protocol, affecting Connectors that used the protocol and/or C API. (Bug#25714: http://bugs.mysql.com/25714)

- Optimization of queries with DETERMINISTIC stored functions in the WHERE clause was ineffective: A sequential scan was always used. (Bug#29338: http://bugs.mysql.com/29338)

- SQL_BIG_RESULT had no effect for CREATE TABLE ... SELECT SQL_BIG_RESULT ... statements. (Bug#15130: http://bugs.mysql.com/15130)

- For InnoDB tables, MySQL unnecessarily sorted records in certain cases when the records were retrieved by InnoDB in the proper order already. (Bug#28591: http://bugs.mysql.com/28591)

- EXPLAIN produced Impossible where for statements of the form SELECT ... FROM t WHERE c=0, where c was an ENUM column defined as a primary key. (Bug#29661: http://bugs.mysql.com/29661)

- On Windows, ALTER TABLE hung if records were locked in share mode by a long-running transaction. (Bug#29644: http://bugs.mysql.com/29644)

- A field packet with NULL fields caused a libmysqlclient crash. (Bug#29494: http://bugs.mysql.com/29494)

- A byte-order issue in writing a spatial index to disk caused bad index files on some systems. (Bug#29070: http://bugs.mysql.com/29070)

- mysqldump produced output that incorrectly discarded the NO_AUTO_VALUE_ON_ZERO value of the SQL_MODE variable after dumping triggers. (Bug#29788: http://bugs.mysql.com/29788)

- Adding DISTINCT could cause incorrect rows to appear in a query result. (Bug#29911: http://bugs.mysql.com/29911)

- Killing an INSERT DELAYED thread caused a server crash. (Bug#29431: http://bugs.mysql.com/29431)

- For updates to InnoDB tables, a TIMESTAMP column with the ON UPDATE CURRENT_TIMESTAMP attribute could be updated even when no values actually changed. (Bug#29310: http://bugs.mysql.com/29310)

- The special "zero" ENUM value was coerced to the normal empty string ENUM value during a column-to-column copy. This affected CREATE ... SELECT statements and SELECT statements with aggregate functions on ENUM columns in the GROUP BY clause. (Bug#29360: http://bugs.mysql.com/29360)

- Conversion of ASCII DEL (0x7F) to Unicode incorrectly resulted in QUESTION MARK (0x3F) rather than DEL. (Bug#29499: http://bugs.mysql.com/29499)

- A left join between two views could produce incorrect results. (Bug#29604: http://bugs.mysql.com/29604)

- For MEMORY tables, the index_merge union access method could return incorrect results. (Bug#29740: http://bugs.mysql.com/29740)

- If query execution involved a temporary table, GROUP_CONCAT() could return a result with an incorrect character set. (Bug#29850: http://bugs.mysql.com/29850)

- Slave servers could incorrectly interpret an out-of-memory error from the master and reconnect using the wrong binary log position. (Bug#24192: http://bugs.mysql.com/24192)

- Comparison of TIME values using the BETWEEN operator led to string comparison, producing incorrect results in some cases. Now the values are compared as integers. (Bug#29739: http://bugs.mysql.com/29739)

- An incorrect result was returned when comparing string values that were converted to TIME values with CAST(). (Bug#29555: http://bugs.mysql.com/29555)

- If InnoDB reached its limit on the number of concurrent transactions (1023), it wrote a descriptive message to the error log but returned a misleading error message to the client, or an assertion failure occurred. (Bug#18828: http://bugs.mysql.com/18828)

- On Windows, the mysql client died if the user entered a statement and Return after entering Control-C. (Bug#29469: http://bugs.mysql.com/29469)

- For the general query log, logging of prepared statements executed via the C API differed from logging of prepared statements performed with PREPARE and EXECUTE. Logging for the latter was missing the Prepare and Execute lines. (Bug#13326: http://bugs.mysql.com/13326)

- Under heavy load with a large query cache, invalidating part of the cache could cause the server to freeze (that is, to be unable to service other operations until the invalidation was complete). (Bug#21074: http://bugs.mysql.com/21074)

- 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/26141)

- On 64-bit platforms, the filesort code (for queries with GROUP BY or ORDER BY) could crash due to an incorrect pointer size. (Bug#29610: http://bugs.mysql.com/29610)

- Using the DATE() function in a WHERE clause did not return any records after encountering NULL. However, using TRIM or CAST produced the correct results. (Bug#29898: http://bugs.mysql.com/29898)

- Using the --skip-add-drop-table option with mysqldump generated incorrect SQL if the database included any views. The recreation of views requires the creation and removal of temporary tables. This option suppressed the removal of those temporary tables. The same applied to --compact since this option also invokes --skip-add-drop-table. (Bug#28524: http://bugs.mysql.com/28524)

- A race condition in the interaction between MyISAM and the query cache code caused the query cache not to invalidate itself for concurrently inserted data. (Bug#28249: http://bugs.mysql.com/28249)

- The full-text parser could enter an infinite loop if it encountered an illegal multi-byte sequence or a sequence that has no mapping to Unicode. (Bug#29464: http://bugs.mysql.com/29464)

- Failure to consider collation when comparing space characters could lead to incorrect index entry order, making it impossible to find some index values. (Bug#29461: http://bugs.mysql.com/29461)

- Several InnoDB assertion failures were corrected. (Bug#25645: http://bugs.mysql.com/25645)

- InnoDB displayed an incorrect error message when a CREATE TABLE statement exceeded the InnoDB maximum allowable row size. (Bug#21101: http://bugs.mysql.com/21101)

- InnoDB produced an unnecessary (and harmless) warning: InnoDB: Error: trying to declare trx to enter InnoDB, but InnoDB: it already is declared. (Bug#20090: http://bugs.mysql.com/20090)

- Backup software can cause ERROR_SHARING_VIOLATION or ERROR_LOCK_VIOLATION conditions during file operations. InnoDB now retries forever until the condition goes away. (Bug#9709: http://bugs.mysql.com/9709)

- In strict SQL mode, errors silently stopped the SQL thread even for errors named using the --slave-skip-errors option. (Bug#28839: http://bugs.mysql.com/28839)

- MyISAM corruption could occur with the cp932_japanese_ci collation for the cp932 character set due to incorrect comparison for trailing space. (Bug#29333: http://bugs.mysql.com/29333) - Searching a FULLTEXT index for a word with the boolean mode truncation operator could cause an infinite loop. (Bug#29445: http://bugs.mysql.com/29445)

- CHECK TABLE could erroneously report table corruption for a CSV table if multiple threads were modifying the table at the same time. (Bug#29253: http://bugs.mysql.com/29253)

- Clients using SSL could hang the server. (Bug#29579: http://bugs.mysql.com/29579) - Single-row inserts could report a row count greater than one. (Bug#29692: http://bugs.mysql.com/29692)

- For a table with a DATE column date_col such that selecting rows with WHERE date_col = 'date_val 00:00:00' yielded a non-empty result, adding GROUP BY date_col caused the result to be empty. (Bug#29729: http://bugs.mysql.com/29729)

- If a stored procedure was created and invoked prior to selecting a default database with USE, a No database selected error occurred. (Bug#28551: http://bugs.mysql.com/28551) - Indexing column prefixes in InnoDB tables could cause table corruption. (Bug#28138: http://bugs.mysql.com/28138)

- SHOW INNODB STATUS caused an assertion failure under high load. (Bug#22819: http://bugs.mysql.com/22819)

- If a slave timed out while registering with the master to which it was connecting, auto-reconnect failed thereafter. (Bug#19328: http://bugs.mysql.com/19328) - For the embedded server, the mysql_stmt_store_result() C API function caused a memory leak for empty result sets. (Bug#29687: http://bugs.mysql.com/29687)

- mysql-stress-test.pl and mysqld_multi.server.sh were missing from some binary distributions. (Bug#21023: http://bugs.mysql.com/21023, Bug#25486: http://bugs.mysql.com/25486)

- SELECT ... INTO OUTFILE followed by LOAD DATA could result in garbled characters when the FIELDS ENCLOSED BY clause named a delimiter of '0', 'b', 'n', 'r', 't', 'N', or 'Z' due to an interaction of character encoding and doubling for data values containing the enclosed-by character. (Bug#29294: http://bugs.mysql.com/29294) - A duplicate-key error message could display an incorrect key value when not all columns of the key were used to select rows for update. (Bug#28158: http://bugs.mysql.com/28158)

- For some event-creation problems, the server displayed messages that implied the problems were errors when they were only warnings. (Bug#27406: http://bugs.mysql.com/27406)

- Error returns from the time() system call were ignored. (Bug#27198: http://bugs.mysql.com/27198) - ALTER DATABASE did not require at least one option. (Bug#25859: http://bugs.mysql.com/25859)

- Creation of a legal stored procedure could fail if no default database had been selected. (Bug#29050: http://bugs.mysql.com/29050)

- mysqld_safe produced error messages and did not create the error log file under some circumstances. (Bug#29634: http://bugs.mysql.com/29634) - The thread ID was not reset properly after execution of mysql_change_user(), which could cause replication failure when replicating temporary tables. (Bug#29734: http://bugs.mysql.com/29734)

- The FEDERATED storage engine failed silently for INSERT ... ON DUPLICATE KEY UPDATE if a duplicate key violation occurred. FEDERATED does not support ON DUPLICATE KEY UPDATE, so now it correctly returns an ER_DUP_KEY error if a duplicate key violation occurs. (Bug#25511: http://bugs.mysql.com/25511)

- For a multiple-row insert into a FEDERATED table that refers to a remote transactional table, if the insert failed for a row due to constraint failure, the remote table would contain a partial commit (the rows preceding the failed one) instead of rolling back the statement completely. This occurred because the rows were treated as individual inserts. Now FEDERATED performs bulk-insert handling such that multiple rows are sent to the remote table in a batch. This provides a performance improvement and enables the remote table to perform statement rollback properly should an error occur. This capability has the following limitations: + The size of the insert cannot exceed the maximum packet size between servers. If the insert exceeds this size, it is broken into multiple packet and the rollback problem can occur.
+ Bulk-insert handling does not occur for INSERT ... ON DUPLICATE KEY UPDATE. (Bug#25513: http://bugs.mysql.com/25513) - ALTER VIEW is not supported as a prepared statement but was not being rejected. ALTER VIEW is now prohibited as a prepared statement or when called within stored routines. (Bug#28846: http://bugs.mysql.com/28846)

- Calling mysql_options() after mysql_real_connect() could cause clients to crash. (Bug#29247: http://bugs.mysql.com/29247)

- If an ENUM column contained '' as one of its members (represented with numeric value greater than 0), and the column contained error values (represented as 0 and displayed as ''), using ALTER TABLE to modify the column definition caused the 0 values to be given the numeric value of the non-zero '' member. (Bug#29251: http://bugs.mysql.com/29251) - Aggregations in subqueries that refer to outer query columns were not always correctly referenced to the proper outer query. (Bug#27333: http://bugs.mysql.com/27333)

- Use of SHOW BINLOG EVENTS for a non-existent log file followed by PURGE MASTER LOGS caused a server crash. (Bug#29420: http://bugs.mysql.com/29420)

- A number of unsupported constructs --- including prohibited constructs, the UCASE() function, and nested function calls --- were permitted in partitioning expressions. (Bug#18198: http://bugs.mysql.com/18198, Bug#26082: http://bugs.mysql.com/26082, Bug#29308: http://bugs.mysql.com/29308)

- SHOW BINLOG EVENTS displayed incorrect values of End_log_pos for events associated with transactional storage engines. (Bug#22540: http://bugs.mysql.com/22540)

- mysqldump created a stray file when a given a too-long filename argument. (Bug#29361: http://bugs.mysql.com/29361)

- The semantics of BIGINT depended on platform-specific characteristics. (Bug#29079: http://bugs.mysql.com/29079)

- mysqld failed to exit during shutdown. (Bug#29133: http://bugs.mysql.com/29133)

- Inserting a negative number into a CSV table could corrupt it. (Bug#29353: http://bugs.mysql.com/29353)

- Deleting from a CSV table could corrupt it. (Bug#29411: http://bugs.mysql.com/29411)

- For a statement of the form CREATE t1 SELECT integer_constant, the server created the column using the DECIMAL data type for large negative values that are within the range of BIGINT. (Bug#28625: http://bugs.mysql.com/28625)

- Runtime changes to the log_queries_not_using_indexes system variable were ignored. (Bug#28808: http://bugs.mysql.com/28808)

- Under ActiveState Perl, mysql-test-run.pl would not run. (Bug#18415: http://bugs.mysql.com/18415)

- Under ActiveState Perl, mysql-test-run.pl could kill itself when attempting to kill other processes. (Bug#25657: http://bugs.mysql.com/25657)

- Assertion failure could occur for grouping queries that employed DECIMAL user variables with assignments to them. (Bug#29417: http://bugs.mysql.com/29417)

- For CAST(expr AS DECIMAL(M,D)), the limits of 65 and 30 on the precision (M) and scale (D) were not enforced. (Bug#29415: http://bugs.mysql.com/29415)

- Corrupt data resulted from use of SELECT ... INTO OUTFILE 'file_name' FIELDS ENCLOSED BY 'c', where c is a digit or minus sign, followed by LOAD DATA INFILE 'file_name' FIELDS ENCLOSED BY 'c'. (Bug#29442: http://bugs.mysql.com/29442)

- AsText() could fail with a buffer overrun. (Bug#29166: http://bugs.mysql.com/29166)

- Inserting into InnoDB tables and executing RESET MASTER in multiple threads cause assertion failure in debug server binaries. (Bug#28983: http://bugs.mysql.com/28983)

- The index merge union access algorithm could produce incorrect results with InnoDB tables. The problem could also occur for queries that used DISTINCT. (Bug#25798: http://bugs.mysql.com/25798)

- Results for a select query that aliases the column names against a view could duplicate one column while omitting another. This bug could occur for a query over a multiple-table view that includes an ORDER BY clause in its definition. (Bug#29392: http://bugs.mysql.com/29392)

- gcov coverage-testing information was not written if the server crashed. (Bug#29543: http://bugs.mysql.com/29543)

- FULLTEXT indexes could be corrupted by certain gbk characters. (Bug#29299: http://bugs.mysql.com/29299)

- REPLACE, INSERT IGNORE, and UPDATE IGNORE did not work for FEDERATED tables. (Bug#29019: http://bugs.mysql.com/29019)

- CHECK TABLE for ARCHIVE tables could falsely report table corruption or cause a server crash. (Bug#29207: http://bugs.mysql.com/29207)

- SELECT ... FOR UPDATE with partitioned tables could cause a server crash. (Bug#28026: http://bugs.mysql.com/28026)

- Updates to rows in a partitioned table could update the wrong column. (Bug#26827: http://bugs.mysql.com/26827)

- Updates to a CSV table could cause a server crash or update the table with incorrect values. (Bug#28971: http://bugs.mysql.com/28971)

- Dropping a user-defined function could cause a server crash if the function was still in use by another thread. (Bug#27564: http://bugs.mysql.com/27564)

- The server crashed when the size of an ARCHIVE table grew larger than 2GB. (Bug#15787: http://bugs.mysql.com/15787)

- An assertion failure occurred if a query contained a conjunctive predicate of the form view_column = constant in the WHERE clause and the GROUP BY clause contained a reference to a different view column. The fix also enables application of an optimization that was being skipped if a query contained a conjunctive predicate of the form view_column = constant in the WHERE clause and the GROUP BY clause contained a reference to the same view column. (Bug#29104: http://bugs.mysql.com/29104)

- Replication of partitioned tables using the InnoDB storage engine failed with binlog-format=ROW or binlog-format=MIXED. (Bug#28430: http://bugs.mysql.com/28430)

- If a storage engine has its own logging capability, then any statement using both this engine and some other engine not having its own logging could not be correctly logged, due to the fact that entries from one engine could be logged before entries from the other engine were. This did not generate any error messages when it occurred. Now, if multiple storage engines are used in a statement and at least one of them has its own logging capability, then an error message is generated and the statement is not executed. (Bug#28722: http://bugs.mysql.com/28722) Note: Currently, the only storage engine to have its own logging capability is NDBCLUSTER.

- Using the READ COMMITTED transaction isolation level caused mixed and statement-based replication to fail. (Bug#23051: http://bugs.mysql.com/23051)

- The server returned data from SHOW CREATE TABLE statement or a SELECT statement on an INFORMATION_SCHEMA table using the binarycharacterset.(Bug#10491: http://bugs.mysql.com/10491)

- Mixing binary and utf8 columns in a union caused field lengths to be calculated incorrectly, resulting in truncation. (Bug#29205: http://bugs.mysql.com/29205)

- LOCK TABLES was not atomic when more than one InnoDB tables were locked. (Bug#29154: http://bugs.mysql.com/29154)

- Queries that performed a lookup into a BINARY index containing key values ending with spaces caused an assertion failure for debug builds and incorrect results for non-debug builds. (Bug#29087: http://bugs.mysql.com/29087)

- Selecting a column not present in the selected-from table caused an extra error to be produced by SHOW ERRORS. (Bug#28677: http://bugs.mysql.com/28677)

- If an INSERT INTO ... SELECT statement inserted into the same table that the SELECT retrieved from, and the SELECT included ORDER BY and LIMIT clauses, different data was inserted than the data produced by the SELECT executed by itself. (Bug#29095: http://bugs.mysql.com/29095)

- On 64-bit Windows systems, the Config Wizard failed to complete the setup because 64-bit Windows does not resolve dynamic linking of the 64-bit libmysql.dll to a 32-bit application like the Config Wizard. (Bug#14649: http://bugs.mysql.com/14649)

- For a join with GROUP BY and/or ORDER BY and a view reference in the FROM list, the query metadata erroneously showed empty table aliases and database names for the view columns. (Bug#28898: http://bugs.mysql.com/28898)

- For a ucs2 column, GROUP_CONCAT() did not convert separators to the result character set before inserting them, producing a result containing a mixture of two different character sets. (Bug#28925: http://bugs.mysql.com/28925)

- Index-based range reads could fail for comparisons that involved contraction characters (such as ch in Czech or ll in Spanish). (Bug#27345: http://bugs.mysql.com/27345)

- The Windows implementation of pthread_join() was incorrect and could cause crashes. (Bug#26564: http://bugs.mysql.com/26564)

- Sort order of the collation wasn't used when comparing trailing spaces. This could lead to incorrect comparison results, incorrectly created indexes, or incorrect result set order for queries that include an ORDER BY clause. (Bug#29261: http://bugs.mysql.com/29261)

- Many threads accessing a CSV table simultaneously could cause anassertionfailure.(Bug#29252: http://bugs.mysql.com/29252)

- mysqlbinlog --hexdump generated incorrect output due to omission of the `#' comment character for some comment lines. (Bug#28293: http://bugs.mysql.com/28293)

- Index creation could corrupt the table definition in the .frm file: 1) A table with the maximum number of key segments and maximum length key name would have a corrupted .frm file, due to incorrect calculation of the total key length. 2) MyISAM would reject a table with the maximum number of keys and the maximum number of key segments in all keys. (It would allow one less than this total maximum.) Now MyISAM accepts a table defined with the maximum. (Bug#26642: http://bugs.mysql.com/26642)

- Dropping the definer of an active event caused the server to crash. (Bug#28924: http://bugs.mysql.com/28924)

- Executing ALTER EVENT on an event whose definer's event creation privileges had been revoked cause the server to crash. (Bug#28873: http://bugs.mysql.com/28873)

- Creating an event using ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL ... could in some cases cause mysqld to crash. (Bug#28881: http://bugs.mysql.com/28881)

- Under some circumstances, a SELECT ... FROM mysql.event could cause the server to crash. (Bug#29156: http://bugs.mysql.com/29156)

- Some functions when used in partitioning expressions could cause mysqld to crash. (Bug#27084: http://bugs.mysql.com/27084)

- The SUBSTRING() function returned the the entire string instead of an empty string when it was called from a stored procedure and when the length parameter was specified by a variable with the value `0'. (Bug#27130: http://bugs.mysql.com/27130)

- The LOCATE() function returned NULL if any of its arguments evaluated to NULL. Likewise, the predicate, LOCATE(str,NULL) IS NULL, erroneously evaluated to FALSE. (Bug#27932: http://bugs.mysql.com/27932)

- A query with DISTINCT in the select list to which the loose-scan optimization for grouping queries was applied returned an incorrect result set when the query was used with the SQL_BIG_RESULT option. (Bug#25602: http://bugs.mysql.com/25602)

- A network structure was initialized incorrectly, leading to embedded server crashes. (Bug#29117: http://bugs.mysql.com/29117)

- Fixed a case of unsafe aliasing in the source that caused a client library crash when compiled with gcc 4 at high optimization levels. (Bug#27383: http://bugs.mysql.com/27383)