MySQL 5.1.21-beta has been released

[Joerg Bruehe]

Dear MySQL users,

We are proud to present to you the MySQL Server 5.1.21-beta
release, a new beta version of the popular open source database.

Bear in mind that this is a beta release, and as with any other
pre-production release, caution should be taken when installing on
production level systems or systems with critical data. For production
level systems using 5.0, we would like to direct your attention to the
product description of MySQL Enterprise at:

           http://mysql.com/products/enterprise/

The MySQL 5.1.21-beta release is now available in source and binary form
for a number of platforms from our download pages at

           http://dev.mysql.com/downloads/

and mirror sites. Note that not all mirror sites may be up to date at
this point in time, so if you can't find this version on some mirror,
please try again later or choose another download site.

Please also note that some of our mirrors are currently experiencing
problems that may result in serving corrupted files. We are working with
the mirror maintainers to resolve this.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches etc.:

           http://forge.mysql.com/wiki/Contributing

The following section lists the changes from version to version in the
MySQL source code since the latest released version of MySQL 5.1, the
MySQL 5.1.20-beta release. It can also be viewed online at

           http://dev.mysql.com/doc/refman/5.1/en/news-5-1-21.html


Functionality added or changed:
   * 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)

Bugs fixed:
   * 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 packets 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)

Enjoy !
Joerg

-- 
Joerg Bruehe, Senior Production Engineer
MySQL AB, www.mysql.com