==========

Functionality added or changed:

  * Providing an empty string as the catalog argument to SQLTables()
    will return an empty result set. A catalog must have a name.

  * Remove use of "old" SQLLEN/SQLULEN types aliases. They are not
    supported in unixODBC 2.2.13 and later 64-bit builds. Removed
    SQLROWCOUNT, SQLROWSETSIZE, SQLTRANSID, SQLROWOFFSET.

  * Connection parameters can be specified individually instead of
    using OPTIONS bitflags. (See connection parameters documentation)

  * Edit controls for INITSTMT and CHARSET DSN options are added to the native
    Windows GUI. (Bug#40932)

  * Length/Indicator pointer is now stored and used internally as pointer to
    SQLLEN and not to SQLINTEGER. Using SQLINTEGER pointers as
    StrLen_or_IndPtr parameter of SQLBindParameter/SQLBindCol may cause crash
    on 64bit platforms.

  * Query log is not overwritten, but appended instead. (Bug#44965)

  * Fixed tab order in Windows datasource config dialog. (Bug#42905)

Bugs fixed:

  * Add support for data-at-execution with positioned insert/update
    (Bug#37649)

  * Output string length from SQLDriverConnect() includes NULL-term
    (Bug#38949)

  * SQLGetInfo() returns 0 for SQL_CATALOG_USAGE info (Bug#39560)

  * SQLDriverConnect() may truncate output string erroneously
    (Bug#37278)

  * SQLTables() doesn't properly handle empty strings to list catalogs
    and tables. (Bug#39561)

  * Calling SQLDriverConnect() with no output buffer will crash if not
    prompting. (Bug#40316)

  * SQLTables() doesn't return the catalog name if the table is given
    and the catalog argument is NULL. (Bug#39957)

  * Driver crashes when attempting to retrieve data in a character set
    not compiled into libmysql. (Bug#39831)

  * SQLGetTypeInfo() doesn't return any rows SQL_TIMESTAMP on an ODBC v2
    connection. (Bug#30626)

  * Positioned update with SQL_C_NUMERIC loses prec/scale values
    (Bug#39961)

  * ADO adUseServer cursor is lost after updating adLongVarWChar field
    (Bug#26950)

  * Calling SQLDescribeCol() with a NULL buffer and non-zero buffer
    length causes a crash. (Bug#41942)

  * NULL parameters don't work correctly with ADO. (Bug#41256)

  * Unable to retrieve null DECIMAL fields in ADO. (Bug#41081)

  * Fix positioned update using data-at-execution, bind offsets and
    row-wise binding. (Bug#36071)

  * SQLConfigDataSource may fail with: Cannot find driver (Bug#41796)

  * FLAG_NO_BIGINT still returns bigint for SQLDescribeCol()
    (Bug#17679)

  * Random access violation exceptions (0xC0000005) in ASP scripts in the
    SQLSetConnectAttrW. (Bug#44971)

  * Binding SQL_C_BIT to an integer column didn't work. (Bug#39644)

  * Inserting a new record using SQLSetPos if the table is from different than
    current catalog. (Bug#41946)

Includes changes from Connector/ODBC 3.51.27.

Built against the client library from MySQL 5.1.34sp1.

Functionality added or changed:

* Incompatible Change: If you upgrade to MySQL 5.4.3 from an
 earlier 5.4 release, the server may fail to start due to
 changes in the default values of innodb_log_files_in_group and
 innodb_log_file_size, which differ from those in earlier 5.4
 releases. You should discard the old InnoDB log files and let
 MySQL 5.4.3 create new ones. It is necessary to shut down your
 current server cleanly so that no outstanding transaction
 information remains in the log. The procedure to use depends
 on the value of innodb_fast_shutdown used in your current
 server:

    + If innodb_fast_shutdown is not set to 2: Stop your
      current MySQL server and make sure that it shuts down
      without errors (to ensure that there is no information
      for outstanding transactions in the log). Copy the old
      log files into a safe place in case something went wrong
      during the shutdown and you need them to recover the
      tablespace. Delete the old log files and edit my.cnf if
      necessary to specify the desired log file configuration.
      Then upgrade to MySQL 5.4.3 and start the new server.
      mysqld sees that no InnoDB log files exist at startup and
      creates new ones.

    + If innodb_fast_shutdown is set to 2: Shut down your
      current server, set innodb_fast_shutdown to 1, and
      restart the server. The server should be allowed to
      recover. Then you should shut down the server again and
      follow the procedure described in the preceding item to
      change InnoDB log file size. Set innodb_fast_shutdown
      back to 2 and start the MySQL 5.4.3 server.

* Incompatible Change: The following list indicates InnoDB
 configuration changes in MySQL 5.4.3, compared to previous
 versions of MySQL 5.4. For a description of cumulative changes
 in MySQL 5.4 compared to MySQL 5.1, see Section 1.4.1, "What
 Is New in MySQL 5.4."

 The default value of these system variables was changed:

           Variable          Change in default value
 innodb_autoextend_increment From 64MB to 8MB
 innodb_buffer_pool_size     From 1GB to 128MB
 innodb_log_buffer_size      From 16MB to 8MB
 innodb_log_file_size        From 128MB to 5MB
 innodb_log_files_in_group   From 3 to 2
 innodb_read_io_threads      From 8 to 4
 innodb_write_io_threads     From 8 to 4

 These default value changes in most cases revert changes made
 in earlier MySQL 5.4 releases. The result is that the defaults
 are more similar to those in MySQL 5.1.

* On Linux (and perhaps other systems), the performance of MySQL
 Server can be improved by using a different malloc()
 implementation, developed by Google and called tcmalloc. The
 gain is noticeable with a higher number of simultaneous users.
 MySQL 5.4.1 was linked against this library, which improved
 performance but imposed some restrictions. As a result of
 these restrictions, MySQL 5.4.3 uses a different approach:

    + The server is linked against the default malloc()
      provided by the respective platform.

    + Binary distributions for Linux include
      libtcmalloc_minimal.so (a shared library that can be
      linked against at runtime) in pkglibdir (that is, the
      same directory within the package where server plugins
      and similar object files are located). The version of
      tcmalloc included with MySQL 5.4.3 comes from
      google-perftools 1.4.

      If you want to try tcmalloc but are using a binary
      distribution for a non-Linux platform or a source
      distribution, you can install Google's tcmalloc.  Some
      distributions provide it in a google-perftools package or
      with a similar name, or you can download it from Google at
      http://code.google.com/p/google-perftools/ and compile it
      yourself.

    + mysqld_safe now supports a --malloc-lib option that
      enables administrators to specify that mysqld should use
      tcmalloc.

 The --malloc-lib option works by modifying the LD_PRELOAD
 environment value to affect dynamic linking to enable the
 loader to find the memory-allocation library when mysqld runs:

    + If the option is not given, or is given without a value
      (--malloc-lib=), LD_PRELOAD is not modified and no
      attempt is made to use tcmalloc.

    + If the option is given as --malloc-lib=tcmalloc,
      mysqld_safe looks for a tcmalloc library in /usr/lib and
      then in the MySQL pkglibdir location (for example,
      /usr/local/mysql/lib or whatever is appropriate). If
      tmalloc is found, its path name is added to the beginning
      of the LD_PRELOAD value for mysqld. If tcmalloc is not
      found, mysqld_safe aborts with an error.

    + If the option is given as
      --malloc-lib=/path/to/some/library, that full path is
      added to the beginning of the LD_PRELOAD value. If the
      full path points to a nonexistent or unreadable file,
      mysqld_safe aborts with an error.

    + For cases where mysqld_safe adds a path name to
      LD_PRELOAD, it adds the path to the beginning of any
      existing value the variable already has.

 As a result of the preceding changes, Linux users can use the
 libtcmalloc_minimal.so now included in binary packages by
 adding these lines to the my.cnf file:

 [mysqld_safe]
 malloc-lib=tcmalloc

 Those lines also suffice for users on any platform who have
 installed a tcmalloc package in /usr/lib. To use a specific
 tcmalloc library, specify its full path name. Example:

 [mysqld_safe]
 malloc-lib=/opt/lib/libtcmalloc_minimal.so

 (Bug#47549: http://bugs.mysql.com/47549)


Bugs fixed:

* Performance: For MyISAM tables with bulk_insert_buffer_size
 values larger than 256KB, the performance of bulk insert
 operations such as multiple-row INSERT and INSERT ... SELECT
 operations has been improved greatly when up to a hundred rows
 are inserted at the same time.
 (Bug#44723: http://bugs.mysql.com/44723)

* Partitioning: Replication: Attempting to replicate an INSERT
 ... SELECT statement on a partitioned table using row-based
 replication caused the slave to crash.
 (Bug#44108: http://bugs.mysql.com/44108)

* Partitioning: When reorganizing partitions, not all affected
 subpartitions were removed prior to renaming. One way in which
 the issue was visible was that attempting to reorganize two
 partitions into a single partition having the same name as one
 of the original partitions could lead to a crash of the
 server. (Bug#47029: http://bugs.mysql.com/47029)
 See also Bug#45961: http://bugs.mysql.com/45961,
 Bug#43729: http://bugs.mysql.com/43729.

* Partitioning: An INSERT ... SELECT statement on an empty
 partition of a partitioned table failed with ERROR 1030
 (HY000): Got error 124 from storage engine. This issue also
 caused queries run against a partitioned table while a LOAD
 DATA CONCURRENT INFILE statement was in progress to fail with
 the same error. (Bug#46639: http://bugs.mysql.com/46639)
 See also Bug#35845: http://bugs.mysql.com/35845,
 Bug#44657: http://bugs.mysql.com/44657,
 Bug#45840: http://bugs.mysql.com/45840.

* Partitioning: An online or fast ALTER TABLE of a partitioned
 table could leave behind temporary files in the database
 directory. (Bug#46483: http://bugs.mysql.com/46483)

* Partitioning: A partitioned table having a TIMESTAMP column
 with a default value of CURRENT_TIMESTAMP and this column was
 not defined using an ON UPDATE option, an ALTER TABLE ...
 REORGANIZE PARTITION statement on the table caused the
 TIMESTAMP column value to be set to CURRENT_TIMESTAMP
 regardless. (Bug#46478: http://bugs.mysql.com/46478)

* Partitioning: Partition pruning did not always work correctly
 when the table's partitioning key used the TO_DAYS() function.
 (Bug#46362: http://bugs.mysql.com/46362)

* Partitioning: Inserting negative values into an AUTO_INCREMENT
 column of a partitioned table could lead to apparently
 unrelated errors or a crash of the server.
 (Bug#45823: http://bugs.mysql.com/45823)

* Partitioning: Attempting to access a partitioned table when
 partitioning support was disabled in a MySQL server binary
 that had been compiled with partitioning support caused the
 server to crash. (Bug#39893: http://bugs.mysql.com/39893)

* Partitioning: Unnecessary calls were made in the server code
 for performing bulk inserts on partitions for which no inserts
 needed to be made. (Bug#35845: http://bugs.mysql.com/35845)
 See also Bug#35843: http://bugs.mysql.com/35843.

* Partitioning: The use of TO_DAYS() in the partitioning
 expression led to selection failures when the column having
 the date value contained invalid dates. This occurred because
 the function returns NULL in such cases, and the partition
 containing NULL values was pruned away. For example, this
 problem occurred if '2001-02-00' was inserted into a DATE
 column of such a table, and a subsequent query on this table
 used WHERE date_col < '2001-02-00' --- while '2001-01-01' is
 less than '2001-02-00', TO_DAYS('2001-02-00') evaluates as
 NULL, and so the row containing '2001-01-01' was not returned.
 Now, for tables using RANGE or LIST partitioning and having
 TO_DAYS() in the partitioning expression, the NULL partition
 is also scanned instead of being ignored.

 The fix for this issue also corrects misbehavior such that a
 query of the form SELECT * FROM table WHERE date_col <
 date_val on a table partitioned by RANGE or LIST was handled
 as though the server SQL mode included ALLOW_INVALID_DATES
 even if this was not actually part of the server SQL mode at
 the time the query was issued.
 (Bug#20577: http://bugs.mysql.com/20577)
 See also Bug#18198: http://bugs.mysql.com/18198,
 Bug#32021: http://bugs.mysql.com/32021,
 Bug#46362: http://bugs.mysql.com/46362.

* Replication: Performing a multi-row update of the
 AUTO_INCREMENT column of a transactional table could result in
 an inconsistency between master and slave when there was a
 trigger on the transactional table that updated a
 non-transactional table. When such an update failed on the
 master, no rows were updated on the master, but some rows
 could (erroneously) be updated on the slave.
 (Bug#46864: http://bugs.mysql.com/46864)

* Replication: When using the --replicate-rewrite-db option and
 the database referenced by this option on the master was the
 current database when the connection to the slave was closed,
 any temporary tables existing in this database were not
 properly dropped. (Bug#46861: http://bugs.mysql.com/46861)

* Replication: When a statement that changed both transactional
 and non-transactional tables failed, the transactional changes
 were automatically rolled back on the master but the slave
 ignored the error and did not roll them back, thus leading to
 inconsistencies between master and slave.

 This issue is fixed by automatically rolling back a statement
 that fails on the slave; however, the transaction is not
 rolled back unless a corresponding ROLLBACK statement is found
 in the relay log file.
 (Bug#46130: http://bugs.mysql.com/46130)
 See also Bug#33864: http://bugs.mysql.com/33864.

* Replication: When using row-based replication, importing a
 dump made with mysqldump and replicating a row with an
 AUTO_INCREMENT column set to 0, with NO_AUTO_VALUE_ON_ZERO
 active on the master, the row was inserted successfully on the
 master; however any setting for NO_AUTO_VALUE_ON_ZERO was
 ignored on the slave. When the AUTO_INCREMENT column was
 incremented, this caused replication to fail on the slave due
 to a duplicate key error. In some cases it could also cause
 the slave to crash. (Bug#45999: http://bugs.mysql.com/45999)

* Replication: When slave_transaction_retries is set, a
 statement that replicates, but is then rolled back due to a
 deadlock on the slave, should be retried. However, in certain
 cases, replication was stopped with error 1213 (Deadlock found
 when trying to get lock; try restarting transaction) instead,
 even when this variable was set.
 (Bug#45694: http://bugs.mysql.com/45694)

* Replication: The binary logging behavior (and thus, the
 replication behavior) of CREATE DATABASE IF NOT EXISTS, CREATE
 TABLE IF NOT EXISTS, and CREATE EVENT IF NOT EXISTS was not
 consistent among these statements, nor with that of DROP
 DATABASE IF EXISTS, DROP TABLE IF EXISTS, and DROP EVENT IF
 EXISTS: A DROP ... IF EXISTS statement is always logged even
 if the database object named in the statement does not exist.
 However, of the CREATE ... IF NOT EXISTS statements, only the
 CREATE EVENT IF NOT EXISTS statement was logged when the
 database object named in the statement already existed.

 Now, every CREATE ... IF NOT EXISTS statement is written to
 the binary log (and thus replicated), whether the database
 object named in the statement exists or not. For more
 information, see Section 16.3.1.3, "Replication of CREATE ...
 IF NOT EXISTS Statements."

 Exception.  Replication and logging of CREATE TABLE IF NOT
 EXISTS ... SELECT continues to be handled according to
 existing rules. See Section 16.3.1.4, "Replication of CREATE
 TABLE ... SELECT Statements," for more information.
 (Bug#45574: http://bugs.mysql.com/45574)

* Replication: When using statement-based replication,
 database-level character sets were not always honored by the
 replication SQL thread. This could cause data inserted on the
 master using LOAD DATA to be replicated using the wrong
 character set.

 Note
 This was not an issue when using row-based replication.
 (Bug#45516: http://bugs.mysql.com/45516)

* Replication: In some cases, a STOP SLAVE statement could cause
 the replication slave to crash. This issue was specific to
 MySQL on Windows or Macintosh platforms.
 (Bug#45238: http://bugs.mysql.com/45238,
 Bug#45242: http://bugs.mysql.com/45242,
 Bug#45243: http://bugs.mysql.com/45243,
 Bug#46013: http://bugs.mysql.com/46013,
 Bug#46014: http://bugs.mysql.com/46014,
 Bug#46030: http://bugs.mysql.com/46030)
 See also Bug#40796: http://bugs.mysql.com/40796.

* Replication: Creating a scheduled event whose DEFINER clause
 was either set to CURRENT_USER or not set explicitly caused
 the master and the slave to become inconsistent. This issue
 stems from the fact that, in both cases, the DEFINER is set to
 the CURRENT_USER of the current thread. (On the master, the
 CURRENT_USER is the mysqld user; on the slave, the
 CURRENT_USER is empty.)

 This behavior has been modified as follows:

    + If CURRENT_USER is used as the DEFINER, it is replaced
      with the value of CURRENT_USER before the CREATE EVENT
      statement is written to the binary log.

    + If the definer is not set explicitly, a DEFINER clause
      using the value of CURRENT_USER is added to the CREATE
      EVENT statement before it is written to the binary log.
 (Bug#44331: http://bugs.mysql.com/44331)
 See also Bug#42217: http://bugs.mysql.com/42217.

* Replication: When using the statement-based logging format,
 the only possible safe combination of transactional and
 non-transactional statements within the same transaction is to
 perform any updates on non-transactional tables (such as
 MyISAM tables) first, before updating any transactional tables
 (such as those using the InnoDB storage engine). This is due
 to the fact that, although a modification made to a
 non-transactional table is immediately visible to other
 connections, the update is not immediately written to the
 binary log, which can lead to inconsistencies between master
 and slave. (Other combinations may hide a causal dependency,
 thus making it impossible to write statements updating
 non-transactional tables to the binary log in the correct
 order.)

 However, in some cases, this situation was not handled
 properly, and the determination whether a given statement was
 safe or not under these conditions was not always correct. In
 particular, a multi-table update that affected both
 transactional and non-transactional tables or a statement
 modifying data in a non-transactional table having a trigger
 that operated on a transactional table (or the reverse) was
 not determined to be unsafe when it should have been.

 With this fix, the following determinations regarding
 replication safety are made when combining updates to
 transactional and non-transactional tables within the same
 transaction in statement-based logging mode:

   1. Any statement modifying data in a non-transactional table
      within a given transaction is considered safe if it is
      issued prior to any data modification statement accessing
      a transactional table within the same transaction.

   2. A statement that updates transactional tables only is
      always considered safe.

   3. A statement affecting both transactional and
      non-transactional tables within a transaction is always
      considered unsafe. It is not necessary that both tables
      be modified for this to be true; for example, a statement
      such as INSERT INTO innodb_table SELECT * FROM
      myisam_table is also considered unsafe.

 Note
 The current fix is valid only when using statement-based
 logging mode; we plan to address similar issues occurring when
 using the MIXED or ROW format in a future MySQL release.
 (Bug#28976: http://bugs.mysql.com/28976)

* The ARCHIVE storage engine lost records during a bulk insert.
 (Bug#46961: http://bugs.mysql.com/46961)

* CONCAT_WS() could return incorrect results due to an argument
 buffer also being used as a result buffer.
 (Bug#46815: http://bugs.mysql.com/46815)

* Stack overflow checking did not account for the size of the
 structure stored in the heap.
 (Bug#46807: http://bugs.mysql.com/46807)

* The server crashed when re-using outer column references in
 correlated subqueries when the enclosing query used a temp
 table. (Bug#46791: http://bugs.mysql.com/46791)

* The server could crash for queries with the following
 elements: 1. An "impossible where" in the outermost SELECT; 2.
 An aggregate in the outermost SELECT; 3. A correlated subquery
 with a WHERE clause that includes an outer field reference as
 a top-level WHERE sargable predicate;
 (Bug#46749: http://bugs.mysql.com/46749)

* Assertion failure could result from repeated execution of a
 stored procedure containing an incorrect query with a
 subselect. (Bug#46629: http://bugs.mysql.com/46629)

* CREATE TABLE ... SELECT could cause assertion failure if a
 table already existed with the same name and contained an
 AUTO_INCREMENT column.
 (Bug#46616: http://bugs.mysql.com/46616)

* SHOW CREATE TRIGGER for a MERGE table trigger caused an
 assertion failure. (Bug#46614: http://bugs.mysql.com/46614)

* In queries for which the loose index scan access method was
 chosen, using a condition of the form col_name rather than the
 equivalent col_name <> 0 caused an assertion failure.
 (Bug#46607: http://bugs.mysql.com/46607)

* The server ignored the setting of sync_frm for CREATE TABLE
 ... LIKE. (Bug#46591: http://bugs.mysql.com/46591)

* TRUNCATE TABLE for a table that was opened with HANDLER did
 not close the handler and left it in an inconsistent state
 that could lead to a server crash. Now TRUNCATE TABLE for a
 table closes all open handlers for the table.
 (Bug#46456: http://bugs.mysql.com/46456)

* An attempt to create a table with the same name as an existing
 view could cause a server crash.
 (Bug#46384: http://bugs.mysql.com/46384)

* A parser problem prevented properly stripping backquotes from
 an argument to a user-defined function (UDF). If the UDF was
 in an ORDER BY clause, its name would not be properly resolved
 against an alias with the same name in the select list.
 (Bug#46259: http://bugs.mysql.com/46259)

* A query containing a subquery in the FROM clause and PROCEDURE
 ANALYSE() caused a server crash.
 (Bug#46184: http://bugs.mysql.com/46184)

* Certain SELECT statements containing DISTINCT, GROUP BY, and
 HAVING clauses could hang in an infinite loop.
 (Bug#46159: http://bugs.mysql.com/46159)

* Killing a query that was performing a sort could result in a
 memory leak. (Bug#45962: http://bugs.mysql.com/45962)

* A Valgrind error when opening the init_file file was
 corrected. (Bug#45894: http://bugs.mysql.com/45894)

* CREATE TEMPORARY TABLE failed for InnoDB tables on systems
 with case-insensitive file systems when lower_case_table_names
 = 2 and the pathname of the temporary file directory contained
 uppercase characters. (Bug#45638: http://bugs.mysql.com/45638)

* Truncation of DECIMAL values could lead to assertion failures;
 for example, when deducing the type of a table column from a
 literal DECIMAL value.
 (Bug#45261: http://bugs.mysql.com/45261)

* Debug builds of the server on Windows crashed in debugging
 code. (Bug#45118: http://bugs.mysql.com/45118)

* The default value of innodb_buffer_pool_size was set to 1GB in
 MySQL 5.4.0. This was too large for many installations, so the
 default has been lowered to 128MB.
 (Bug#44408: http://bugs.mysql.com/44408)

* SHOW ERRORS returned an empty result set after an attempt to
 drop a nonexistent table.
 (Bug#42364: http://bugs.mysql.com/42364)

* A test for stack growth failed on some platforms, leading to
 server crashes. (Bug#42213: http://bugs.mysql.com/42213)

* A buffer overflow could occur during handling of IS NULL
 ranges. (Bug#37044: http://bugs.mysql.com/37044)

* mysqladmin --wait ping crashed on Windows systems.
 (Bug#35132: http://bugs.mysql.com/35132)

* myisamchk performed parameter value casting at startup that
 generated unnecessary warning messages.
 (Bug#33785: http://bugs.mysql.com/33785)

* When using the ARCHIVE storage engine, SHOW TABLE STATUS
 displayed incorrect information for Max_data_length,
 Data_length and Avg_row_length.
 (Bug#29203: http://bugs.mysql.com/29203)

=======================================================================

C.1.1. Changes in MySQL 5.1.39

   Bugs fixed:

     * Partitioning: An INSERT ... SELECT statement on an empty
       partition of a partitioned table failed with ERROR 1030
       (HY000): Got error 124 from storage engine. This issue also
       caused queries run against a partitioned table while a LOAD
       DATA CONCURRENT INFILE statement was in progress to fail with
       the same error. (Bug#46639: http://bugs.mysql.com/46639)
       See also Bug#35845: http://bugs.mysql.com/35845,
       Bug#44657: http://bugs.mysql.com/44657,
       Bug#45840: http://bugs.mysql.com/45840.

     * Partitioning: A partitioned table having a TIMESTAMP column
       with a default value of CURRENT_TIMESTAMP and this column was
       not defined using an ON UPDATE option, an ALTER TABLE ...
       REORGANIZE PARTITION statement on the table caused the
       TIMESTAMP column value to be set to CURRENT_TIMESTAMP
       regardless. (Bug#46478: http://bugs.mysql.com/46478)

     * Partitioning: Attempting to access a partitioned table when
       partitioning support was disabled in a MySQL server binary
       that had been compiled with partitioning support caused the
       server to crash. (Bug#39893: http://bugs.mysql.com/39893)

     * Partitioning: The use of TO_DAYS() in the partitioning
       expression led to selection failures when the column having
       the date value contained invalid dates. This occurred because
       the function returns NULL in such cases, and the partition
       containing NULL values was pruned away. For example, this
       problem occurred if '2001-02-00' was inserted into a DATE
       column of such a table, and a subsequent query on this table
       used WHERE date_col < '2001-02-00' --- while '2001-01-01' is
       less than '2001-02-00', TO_DAYS('2001-02-00') evaluates as
       NULL, and so the row containing '2001-01-01' was not returned.
       Now, for tables using RANGE or LIST partitioning and having
       TO_DAYS() in the partitioning expression, the NULL partition
       is also scanned instead of being ignored.
       The fix for this issue also corrects misbehavior such that a
       query of the form SELECT * FROM table WHERE date_col <
       date_val on a table partitioned by RANGE or LIST was handled
       as though the server SQL mode included ALLOW_INVALID_DATES
       even if this was not actually part of the server SQL mode at
       the time the query was issued.
       (Bug#20577: http://bugs.mysql.com/20577)
       See also Bug#18198: http://bugs.mysql.com/18198,
       Bug#32021: http://bugs.mysql.com/32021,
       Bug#46362: http://bugs.mysql.com/46362.

     * Replication: Performing a multi-row update of the
       AUTO_INCREMENT column of a transactional table could result in
       an inconsistency between master and slave when there was a
       trigger on the transactional table that updated a
       non-transactional table. When such an update failed on the
       master, no rows were updated on the master, but some rows
       could (erroneously) be updated on the slave.
       (Bug#46864: http://bugs.mysql.com/46864)

     * Replication: When using the --replicate-rewrite-db option and
       the database referenced by this option on the master was the
       current database when the connection to the slave was closed,
       any temporary tables existing in this database were not
       properly dropped. (Bug#46861: http://bugs.mysql.com/46861)

     * Replication: When a statement that changed both transactional
       and non-transactional tables failed, the transactional changes
       were automatically rolled back on the master but the slave
       ignored the error and did not roll them back, thus leading to
       inconsistencies between master and slave.
       This issue is fixed by automatically rolling back a statement
       that fails on the slave; however, the transaction is not
       rolled back unless a corresponding ROLLBACK statement is found
       in the relay log file.
       (Bug#46130: http://bugs.mysql.com/46130)
       See also Bug#33864: http://bugs.mysql.com/33864.

     * Replication: When slave_transaction_retries is set, a
       statement that replicates, but is then rolled back due to a
       deadlock on the slave, should be retried. However, in certain
       cases, replication was stopped with error 1213 (Deadlock found
       when trying to get lock; try restarting transaction) instead,
       even when this variable was set.
       (Bug#45694: http://bugs.mysql.com/45694)

     * Replication: The binary logging behavior (and thus, the
       replication behavior) of CREATE DATABASE IF NOT EXISTS, CREATE
       TABLE IF NOT EXISTS, and CREATE EVENT IF NOT EXISTS was not
       consistent among these statements, nor with that of DROP
       DATABASE IF EXISTS, DROP TABLE IF EXISTS, and DROP EVENT IF
       EXISTS: A DROP ... IF EXISTS statement is always logged even
       if the database object named in the statement does not exist.
       However, of the CREATE ... IF NOT EXISTS statements, only the
       CREATE EVENT IF NOT EXISTS statement was logged when the
       database object named in the statement already existed.
       Now, every CREATE ... IF NOT EXISTS statement is written to
       the binary log (and thus replicated), whether the database
       object named in the statement exists or not. For more
       information, see Section 16.3.1.3, "Replication of CREATE ...
       IF NOT EXISTS Statements."
       Exception.  Replication and logging of CREATE TABLE IF NOT
       EXISTS ... SELECT continues to be handled according to
       existing rules. See Section 16.3.1.4, "Replication of CREATE
       TABLE ... SELECT Statements," for more information.
       (Bug#45574: http://bugs.mysql.com/45574)

     * Replication: When using statement-based replication,
       database-level character sets were not always honored by the
       replication SQL thread. This could cause data inserted on the
       master using LOAD DATA to be replicated using the wrong
       character set.

       Note
       This was not an issue when using row-based replication.
       (Bug#45516: http://bugs.mysql.com/45516)

     * Replication: In some cases, a STOP SLAVE statement could cause
       the replication slave to crash. This issue was specific to
       MySQL on Windows or Macintosh platforms.
       (Bug#45238: http://bugs.mysql.com/45238,
       Bug#45242: http://bugs.mysql.com/45242,
       Bug#45243: http://bugs.mysql.com/45243,
       Bug#46013: http://bugs.mysql.com/46013,
       Bug#46014: http://bugs.mysql.com/46014,
       Bug#46030: http://bugs.mysql.com/46030)

     * Replication: Creating a scheduled event whose DEFINER clause
       was either set to CURRENT_USER or not set explicitly caused
       the master and the slave to become inconsistent. This issue
       stems from the fact that, in both cases, the DEFINER is set to
       the CURRENT_USER of the current thread. (On the master, the
       CURRENT_USER is the mysqld user; on the slave, the
       CURRENT_USER is empty.)
       This behavior has been modified as follows:

          + If CURRENT_USER is used as the DEFINER, it is replaced
            with the value of CURRENT_USER before the CREATE EVENT
            statement is written to the binary log.

          + If the definer is not set explicitly, a DEFINER clause
            using the value of CURRENT_USER is added to the CREATE
            EVENT statement before it is written to the binary log.
       (Bug#44331: http://bugs.mysql.com/44331)
       See also Bug#42217: http://bugs.mysql.com/42217.

     * Replication: When using the statement-based logging format,
       the only possible safe combination of transactional and
       non-transactional statements within the same transaction is to
       perform any updates on non-transactional tables (such as
       MyISAM tables) first, before updating any transactional tables
       (such as those using the InnoDB storage engine). This is due
       to the fact that, although a modification made to a
       non-transactional table is immediately visible to other
       connections, the update is not immediately written to the
       binary log, which can lead to inconsistencies between master
       and slave. (Other combinations may hide a causal dependency,
       thus making it impossible to write statements updating
       non-transactional tables to the binary log in the correct
       order.)
       However, in some cases, this situation was not handled
       properly, and the determination whether a given statement was
       safe or not under these conditions was not always correct. In
       particular, a multi-table update that affected both
       transactional and non-transactional tables or a statement
       modifying data in a non-transactional table having a trigger
       that operated on a transactional table (or the reverse) was
       not determined to be unsafe when it should have been.
       With this fix, the following determinations regarding
       replication safety are made when combining updates to
       transactional and non-transactional tables within the same
       transaction in statement-based logging mode:

         1. Any statement modifying data in a non-transactional table
            within a given transaction is considered safe if it is
            issued prior to any data modification statement accessing
            a transactional table within the same transaction.

         2. A statement that updates transactional tables only is
            always considered safe.

         3. A statement affecting both transactional and
            non-transactional tables within a transaction is always
            considered unsafe. It is not necessary that both tables
            be modified for this to be true; for example, a statement
            such as INSERT INTO innodb_table SELECT * FROM
            myisam_table is also considered unsafe.

       Note
       The current fix is valid only when using statement-based
       logging mode; we plan to address similar issues occurring when
       using the MIXED or ROW format in a future MySQL release.
       (Bug#28976: http://bugs.mysql.com/28976)

     * Stack overflow checking did not account for the size of the
       structure stored in the heap.
       (Bug#46807: http://bugs.mysql.com/46807)

     * In queries for which the loose index scan access method was
       chosen, using a condition of the form col_name rather than the
       equivalent col_name <> 0 caused an assertion failure.
       (Bug#46607: http://bugs.mysql.com/46607)

     * Killing a query that was performing a sort could result in a
       memory leak. (Bug#45962: http://bugs.mysql.com/45962)

     * Truncation of DECIMAL values could lead to assertion failures;
       for example, when deducing the type of a table column from a
       literal DECIMAL value.
       (Bug#45261: http://bugs.mysql.com/45261)

     * Bulk insert performance could suffer with large
       read_buffer_size values.
       (Bug#44723: http://bugs.mysql.com/44723)

     * A buffer overflow could occur during handling of IS NULL
       ranges. (Bug#37044: http://bugs.mysql.com/37044)

     * mysqladmin --wait ping crashed on Windows systems.
       (Bug#35132: http://bugs.mysql.com/35132)

=======================================================================

C.1.1. Changes in MySQL 5.1.38

   As of MySQL 5.1.38, the InnoDB Plugin is included in MySQL
   releases, in addition to the built-in version of InnoDB that
   has been included in previous releases. This version of the
   InnoDB Plugin is 1.0.4 and is considered of Beta quality.

   The InnoDB Plugin offers new features, improved performance
   and scalability, enhanced reliability and new capabilities
   for flexibility and ease of use. Among the features of the
   InnoDB Plugin are "Fast index creation," table and index
   compression, file format management, new INFORMATION_SCHEMA
   tables, capacity tuning, multiple background I/O threads, and
   group commit.

   For information about these features, see the InnoDB Plugin
   Manual at
   http://www.innodb.com/products/innodb_plugin/plugin-documentation
   For general information about using InnoDB in MySQL,
   see Section 13.6, "The InnoDB Storage Engine."

   The InnoDB Plugin is included in source and binary
   distributions, except RHEL3, RHEL4, SuSE 9 (x86, x86_64,
   ia64), and generic Linux RPM packages.

   To use the InnoDB Plugin, you must disable the built-in
   version of InnoDB that is also included and instruct the
   server to use InnoDB Plugin instead. To accomplish this, use
   the following lines in your my.cnf file:

     [mysqld]
     ignore-builtin-innodb
     plugin-load=innodb=ha_innodb_plugin.so

   For the plugin-load option, innodb is the name to associate
   with the plugin and ha_innodb_plugin.so is the name of the
   shared object library that contains the plugin code. The
   extension of .so applies for Unix (and similar) systems. For
   HP-UX on HPPA (11.11) or Windows, the extension should be .sl
   or .dll, respectively, rather than .so.

   If the server has problems finding the plugin when it starts
   up, specify the pathname to the plugin directory. For
   example, if plugins are located in the lib/mysql/plugin
   directory under the MySQL installation directory and you have
   installed MySQL at /usr/local/mysql, use these lines in your
   my.cnf file:

     [mysqld]
     ignore-builtin-innodb
     plugin-load=innodb=ha_innodb_plugin.so
     plugin_dir=/usr/local/mysql/lib/mysql/plugin

   The previous examples show how to activate the storage engine
   part of InnoDB Plugin, but the plugin also implements several
   InnoDB-related INFORMATION_SCHEMA tables. (For information
   about these tables, see
   http://www.innodb.com/doc/innodb_plugin-1.0/innodb-information-schema.html)
   To enable these tables, include additional name=library
   pairs to the plugin-load option:

     [mysqld]
     ignore-builtin-innodb
     plugin-load=innodb=ha_innodb_plugin.so
       ;innodb_trx=ha_innodb_plugin.so
       ;innodb_locks=ha_innodb_plugin.so
       ;innodb_cmp=ha_innodb_plugin.so
       ;innodb_cmp_reset=ha_innodb_plugin.so
       ;innodb_cmpmem=ha_innodb_plugin.so
       ;innodb_cmpmem_reset=ha_innodb_plugin.so

   The plugin-load option here is formatted on multiple lines
   for display purposes but should be written in my.cnf using a
   single line without spaces in the option value. On Windows,
   substitute .dll for each instance of the .so extension.

   After the server starts up, verify that InnoDB Plugin has
   been loaded by using the SHOW PLUGINS statement. For example,
   if you have loaded the storage engine and the
   INFORMATION_SCHEMA tables, the output should include lines
   similar to these:

     mysql> SHOW PLUGINS;
     +---------------------+--------+--------------------+---------------------...
     | Name                | Status | Type               | Library             ...
     +---------------------+--------+--------------------+---------------------...
     | InnoDB              | ACTIVE | STORAGE ENGINE     | ha_innodb_plugin.so ...
     | INNODB_TRX          | ACTIVE | INFORMATION SCHEMA | ha_innodb_plugin.so ...
     | INNODB_LOCKS        | ACTIVE | INFORMATION SCHEMA | ha_innodb_plugin.so ...
     | INNODB_CMP          | ACTIVE | INFORMATION SCHEMA | ha_innodb_plugin.so ...
     | INNODB_CMP_RESET    | ACTIVE | INFORMATION SCHEMA | ha_innodb_plugin.so ...
     | INNODB_CMPMEM       | ACTIVE | INFORMATION SCHEMA | ha_innodb_plugin.so ...
     | INNODB_CMPMEM_RESET | ACTIVE | INFORMATION SCHEMA | ha_innodb_plugin.so ...
     +---------------------+--------+--------------------+---------------------...

   If you build MySQL from a source distribution, InnoDB Plugin
   is one of the storage engines that is built by default. Build
   MySQL the way you normally do; for example, by using the
   instructions at Section 2.10, "MySQL Installation Using a
   Source Distribution." After the build completes, you should
   find the plugin shared object file under the
   storage/innodb_plugin directory, and make install should
   install it in the plugin directory. Configure MySQL to use
   InnoDB Plugin as described earlier for binary distributions.

   Functionality added or changed:

     * Replication: With statement-based logging (SBL),
       repeatedly calling statements that are unsafe for SBL
       caused a warning message to be written to the error log
       for each statement, and there was no way to disable this
       behavior. Now the server logs messages about statements
       that are unsafe for statement-based logging only if the
       log_warnings variable is greater than 0.
       (Bug#46265: http://bugs.mysql.com/46265)

     * The undocumented TRANSACTIONAL and PAGE_CHECKSUM keywords
       were removed from the grammar.
       (Bug#45829: http://bugs.mysql.com/45829)

     * Previously, SELECT ... INTO OUTFILE dumped column values
       without character set conversion, which could produce
       data files that cannot be imported without error if
       different columns used different character sets. A
       consequence of this is that mysqldump ignored the
       --default-character-set option if the --tab option was
       given (which causes SELECT ... INTO OUTFILE to be used to
       dump data.)
       INTO OUTFILE now can be followed by a CHARACTER SET
       clause indicating the character set to which dumped
       values should be converted. Also, mysqldump adds a
       CHARACTER SET clause to the SELECT ... INTO OUTFILE
       statement used to dump data, so that
       --default-character-set is no longer ignored if --tab is
       given.
       Other changes are that SELECT ... INTO OUTFILE enforces
       that ENCLOSED BY and ESCAPED BY arguments must be a
       single character, and SELECT ... INTO OUTFILE and LOAD
       DATA INFILE produce warnings if non-ASCII field or line
       separators are specified.
       (Bug#30946: http://bugs.mysql.com/30946)

     * The MySQL euckr character set now can store extended
       codes [81...FE][41..5A,61..7A,81..FE], which makes euckr
       compatible with the Microsoft cp949 character set.

   Bugs fixed:

     * Partitioning: Attempting to create a table using an
       invalid or inconsistent subpartition definition caused
       the server to crash. An example of such a statement is
       shown here:

         CREATE TABLE t2 (s1 INT, s2 INT)
         PARTITION BY LIST (s1) SUBPARTITION BY HASH (s2) SUBPARTITIONS 1
         (
             PARTITION p1 VALUES IN (1),
             PARTITION p2 VALUES IN (2) (SUBPARTITION p3)
         );

       (Bug#46354: http://bugs.mysql.com/46354)

     * Partitioning: When using a debug build of MySQL, if a
       query against a partitioned table having an index on one
       or more DOUBLE columns used that index, the server failed
       with an assertion.
       (Bug#45816: http://bugs.mysql.com/45816)

     * Partitioning: A failed RENAME TABLE operation on a table
       with user-defined partitioning left the table in an
       unusable state, due to only some of the table files
       having been renamed.
       (Bug#30102: http://bugs.mysql.com/30102)

     * Replication: When a statement that changes a
       non-transactional table failed, the transactional cache
       was flushed, causing a mismatch between the execution and
       logging histories. Now we avoid flushing the
       transactional cache unless a COMMIT or ROLLBACK is
       issued. (Bug#46129: http://bugs.mysql.com/46129)

     * Replication: The internal function
       get_master_version_and_clock() (defined in sql/slave.cc)
       ignored errors and passed directly when queries failed,
       or when queries succeeded but the result retrieved was
       empty. Now this function tries to reconnect the master if
       a query fails due to transient network problems, and to
       fail otherwise. The I/O thread now prints a warning if
       the some system variables do not exist on master (in the
       event the master is a very old version of MySQQL,
       compared to the slave.)
       (Bug#45214: http://bugs.mysql.com/45214)

     * Replication: When using the MIXED logging format, after
       creating a temporary table and performing an update that
       switched the logging format to ROW, the format switch
       persisted following the update. This prevented any
       subsequent DDL statements on temporary tables from being
       written to the binary log until the temporary table was
       dropped. (Bug#43046: http://bugs.mysql.com/43046)
       See also Bug#40013: http://bugs.mysql.com/40013.
       This regression was introduced by
       Bug#20499: http://bugs.mysql.com/20499.

     * Replication: If the --log-bin-trust-function-creators
       option is not enabled, CREATE FUNCTION requires one of
       the modifiers DETERMINISTIC, NO SQL, or READS SQL DATA.
       When using statement-based mode, the execution of a
       stored function should follow the same rules; however,
       only functions defined with DETERMINSTIC could actually
       be executed. In addition, the wrong error was generated
       (ER_BINLOG_ROW_RBR_TO_SBR instead of
       ER_BINLOG_UNSAFE_ROUTINE).
       Now execution of stored functions is compatible with
       creation in this regard; when a stored function without
       one of the modifiers above is executed in STATEMENT mode,
       the correct error is raised, and functions defined using
       NO SQL, READS SQL DATA, or both (that is, without using
       DETERMINSTIC) can be excuted.
       (Bug#41166: http://bugs.mysql.com/41166)

     * The test suite was missing from RPM packages.
       (Bug#46834: http://bugs.mysql.com/46834)

     * Incorrect index optimization could lead to incorrect
       results or server crashes.
       (Bug#46454: http://bugs.mysql.com/46454)

     * The server printed warnings at startup about adjusting
       the value of the max_join_size system variable. (These
       were harmless, but might be seen by users as
       significant.) (Bug#46385: http://bugs.mysql.com/46385)

     * After an error such as a table-full condition, INSERT
       IGNORE could cause an assertion failure for debug builds.
       (Bug#46075: http://bugs.mysql.com/46075)

     * An optimization that moved an item from a subquery to an
       outer query could cause a server crash.
       (Bug#46051: http://bugs.mysql.com/46051)

     * Several Valgrind warnings were corrected.
       (Bug#46003: http://bugs.mysql.com/46003,
       Bug#46034: http://bugs.mysql.com/46034,
       Bug#46042: http://bugs.mysql.com/46042)

     * CREATE TABLE ... SELECT could cause a server crash if no
       default database was selected.
       (Bug#45998: http://bugs.mysql.com/45998)

     * For problems reading SSL files during SSL initialization,
       the server wrote error messages to stderr rather than to
       the error log. (Bug#45770: http://bugs.mysql.com/45770)

     * The vendor name change from MySQL AB to Sun Microsystems,
       Inc. in RPM packages was not handled gracefully when
       upgrading MySQL using an RPM package.
       (Bug#45534: http://bugs.mysql.com/45534)

     * A Windows Installation using the GUI installer would fail
       with:

         MySQL Server 5.1 Setup Wizard ended prematurely

         The wizard was interrupted before MySQL Server 5.1. could be
         completely installed.

         Your system has not been modified. To complete installation at
         another time, please run setup again.

         Click Finish to exit the wizard

       This was due to an step in the MSI installer that could
       fail to execute correctly on some environments.
       (Bug#45418: http://bugs.mysql.com/45418)

     * Invalid memory reads could occur using the compressed
       client/server protocol.
       (Bug#45031: http://bugs.mysql.com/45031)

     * The mysql_real_connect() C API function only attempted to
       connect to the first IP address returned for a hostname.
       This could be a problem if a hostname mapped to multiple
       IP address and the server was not bound to the first one
       returned. Now mysql_real_connect() attempts to connect to
       all IPv4/6 addresses that a domain name maps to.
       (Bug#45017: http://bugs.mysql.com/45017)

     * Invalid input could cause invalid memory reads by the
       parser. (Bug#45010: http://bugs.mysql.com/45010)

     * Some files in an AIX tar file distribution unpacked with
       incorrect permissions.
       (Bug#44647: http://bugs.mysql.com/44647)

     * For debug builds, executing a stored procedure as a
       prepared statement could sometimes cause an assertion
       failure. (Bug#44521: http://bugs.mysql.com/44521)

     * Using mysql_stmt_execute() to call a stored procedure
       could cause a server crash.
       (Bug#44495: http://bugs.mysql.com/44495)

     * Creating a new instance after previously removing an
       instance would fail to complete the installation properly
       because the security settings could not be applied
       correctly. (Bug#44428: http://bugs.mysql.com/44428)

     * mysqlslap ignored the --csv option if it was given
       without an argument.
       (Bug#44412: http://bugs.mysql.com/44412)

     * Enabling the event scheduler from within the file
       specified by --init-file caused a server crash.
       (Bug#43587: http://bugs.mysql.com/43587)

     * The server did not always check the return value of calls
       to the hash_init() function.
       (Bug#43572: http://bugs.mysql.com/43572)

     * The table cache lock (LOCK_open) is now an adaptive
       mutex, which should improve performance in workloads
       where this lock is heavily contended.
       (Bug#43435: http://bugs.mysql.com/43435)

     * mysqladmin --count=X --sleep=Y incorrectly delayed Y
       seconds after the last iteration before exiting.
       (Bug#42639: http://bugs.mysql.com/42639)

     * A test for stack growth failed on some platforms, leading
       to server crashes.
       (Bug#42213: http://bugs.mysql.com/42213)

     * mysqladmin did not have enough space allocated for
       tracking all variables when using --vertical or
       --relative with extended-status.
       (Bug#40395: http://bugs.mysql.com/40395)

     * Partitioning a log table caused a server crash.
       (Bug#40281: http://bugs.mysql.com/40281)

     * When using quick access methods to search for rows in
       UPDATE and DELETE statements, there was no check whether
       a fatal error had already been sent to the client while
       evaluating the quick condition. Consequently, a false OK
       (following the error) was sent to the client, causing the
       error to be incorrectly transformed into a warning.
       (Bug#40113: http://bugs.mysql.com/40113)

     * SHOW PROCESSLIST could access freed memory of a stored
       procedure run in a concurrent session.
       (Bug#38816: http://bugs.mysql.com/38816)

     * During installation on Windows, the MySQL Instance
       Configuration Wizard window could be opened at a size too
       small to be usable.
       (Bug#38723: http://bugs.mysql.com/38723)

     * make_binary_distribution did not always generate correct
       distribution names.
       (Bug#37808: http://bugs.mysql.com/37808)

     * The server crashed when executing a prepared statement
       containing a duplicated MATCH() function call in the
       select list and ORDER BY clause; for example, SELECT
       MATCH(a) AGAINST('test') FROM t1 ORDER BY MATCH(a)
       AGAINST('test'). (Bug#37740: http://bugs.mysql.com/37740)

     * The output of mysqldump --tab for views included a DROP
       TABLE statement without the IF EXISTS qualifier.
       (Bug#37377: http://bugs.mysql.com/37377)

     * mysql_upgrade silently ignored the --basedir and
       --datadir options, which it accepts for backward
       compatibility. Now it prints a warning.
       (Bug#36558: http://bugs.mysql.com/36558)

     * mysqlimport was not always compiled correctly to enable
       thread support, which is required for the --use-threads
       option. (Bug#32991: http://bugs.mysql.com/32991)

     * mysqlcheck failed to fix table names when the
       --fix-table-names and --all-in-1 options were both
       specified. (Bug#31821: http://bugs.mysql.com/31821)

     * If the MySQL server was killed without the PID file being
       removed, attempts to stop the server with mysql.server
       stop waited 900 seconds before giving up.
       (Bug#31785: http://bugs.mysql.com/31785)

     * When performing an installation on Windows using the GUI
       installer, the installer would fail to wait long enough
       during installation for the MySQL service to be
       installed, which would cause the installation to fail and
       may cause security settings, such as the root password to
       not be applied correctly.
       (Bug#30525: http://bugs.mysql.com/30525)

     * mysql included extra spaces at the end of some result set
       lines. (Bug#29622: http://bugs.mysql.com/29622)

     * The mysql client inconsistently handled NUL bytes in
       column data in various output formats.
       (Bug#28203: http://bugs.mysql.com/28203)

     * mysqlimport did not correctly quote and escape table
       identifiers and file names.
       (Bug#28071: http://bugs.mysql.com/28071)

     * When installing the Windows service, using quotes around
       command-line configuration parameters could cause the
       quotes to incorrectly placed around the entire
       command-line option, and not just the value.
       (Bug#27535: http://bugs.mysql.com/27535)

     * If the mysql client was built with the readline library
       and the .inputrc file mapped Space to the magic-space
       function, it became impossible to enter spaces.
       (Bug#27439: http://bugs.mysql.com/27439)

     * 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)

Functionality added or changed:

  * Important Change: Replication: RESET MASTER and RESET SLAVE
    now reset the values shown for Last_IO_Error, Last_IO_Errno,
    Last_SQL_Error, and Last_SQL_Errno in the output of SHOW SLAVE
    STATUS. (Bug#44270: http://bugs.mysql.com/44270)
    See also Bug#34654: http://bugs.mysql.com/34654.

Bugs fixed:

  * Security Fix: Partitioning: Accessing a table with user-defined
    partitioning when the server SQL mode included ONLY_FULL_GROUP_BY
    caused the MySQL server to crash. For example, the following
    sequence of statements crashed the server:

    DROP TABLE IF EXISTS t1;

    SET SESSION SQL_MODE='ONLY_FULL_GROUP_BY';

    CREATE TABLE t1(id INT, key(id))
        PARTITION BY HASH(id) PARTITIONS 2;

    (Bug#45807: http://bugs.mysql.com/45807)

  * Important Change: Replication: When using STATEMENT or MIXED
    binary logging format, a statement that changes both
    non-transactional and transactional tables must be written to
    the binary log whenever there are changes to non-transactional
    tables. This means that the statement goes into the binary log
    even when the changes to the transactional tables fail. In
    particular, in the event of a failure such statement is
    annotated with the error number and wrapped inside a pair of
    BEGIN and ROLLBACK statements.
    On the slave, while applying the statement, it is expected
    that the same failure and the rollback prevent the
    transactional changes from persisting. However, statements
    that fail due to concurrency issues such as deadlocks and
    timeouts are logged in the same way, causing the slave to stop
    since the statements are applied sequentially by the SQL
    thread.
    To address this issue, we ignore concurrency failures on the
    slave. Specifically, the following failures are now ignored:
    ER_LOCK_WAIT_TIMEOUT, ER_LOCK_DEADLOCK, and ER_XA_RBDEADLOCK.
    (Bug#44581: http://bugs.mysql.com/44581)

  * Partitioning: Truncating a partitioned MyISAM table did not
    reset the AUTO_INCREMENT value.
    (Bug#35111: http://bugs.mysql.com/35111)

  * Replication: The SHOW SLAVE STATUS connection thread competed
    with the slave SQL thread for use of the error message buffer.
    As a result, the connection thread sometimes received
    incomplete messages. This issue was uncovered with valgrind
    when message strings were passed without NULL terminators,
    causing the error Conditional jump or move depends on
    uninitialised value(s).
    (Bug#45511: http://bugs.mysql.com/45511)
    See also Bug#43076: http://bugs.mysql.com/43076.

  * Replication: Large transactions and statements could corrupt
    the binary log if the size of the cache (as set by
    max_binlog_cache_size) was not large enough to store the
    changes.
    Now, for transactions that do not fit into the cache, the
    statement is not logged, and the statement generates an error
    instead.
    For non-transactional changes that do not fit into the cache,
    the statement is also not logged --- an incident event is
    logged after committing or rolling back any pending
    transaction, and the statement then raises an error.

    Note
    If a failure occurs before the incident event is written the
    binary log, the slave does not stop, and the master does not
    report any errors.
    (Bug#43929: http://bugs.mysql.com/43929)
    See also Bug#37148: http://bugs.mysql.com/37148.

  * Replication: The --database option for mysqlbinlog was ignored
    when using the row-based logging format.
    (Bug#42941: http://bugs.mysql.com/42941)

  * Replication: Shutting down the server while executing FLUSH
    LOGS, CHANGE MASTER TO, or STOP SLAVE could sometimes cause
    mysqld to crash. (Bug#38240: http://bugs.mysql.com/38240)

  * Replication: When reading a binary log that was in use by a
    master or that had not been properly closed (possibly due to a
    crash), the following message was printed: Warning: this
    binlog was not closed properly. Most probably mysqld crashed
    writing it. This message did not take into account the
    possibility that the file was merely in use by the master,
    which caused some users concern who were not aware that this
    could happen.
    To make this clear, the original message has been replaced
    with Warning: this binlog is either is use or was not closed
    properly. (Bug#34687: http://bugs.mysql.com/34687)

  * The server crashed if evaluation of GROUP_CONCAT(... ORDER BY)
    required allocation of a sort buffer but allocation failed.
    (Bug#46080: http://bugs.mysql.com/46080)

  * When creating tables using the IBMDB2I storage engine with the
    ibmdb2i_create_index_option option set to 1, creating an
    IBMDB2I table with a primary key should produce an additional
    index that uses EBCDIC hexadecimal sorting, but this index was
    not created. (Bug#45983: http://bugs.mysql.com/45983)

  * With InnoDB tables, MySQL used a less-selective secondary
    index to avoid a filesort even if a prefix of the primary key
    was much more selective.
    The fix for this problem might cause other queries to run more
    slowly. (Bug#45828: http://bugs.mysql.com/45828)

  * The server crashed for attempts to use REPLACE or INSERT ...
    ON DUPLICATE KEY UPDATE with a view defined using a join.
    (Bug#45806: http://bugs.mysql.com/45806)

  * Some collations were causing IBMDB2I to report inaccurate key
    range estimations to the optimizer for LIKE clauses that
    select substrings. This can be seen by running EXPLAIN. This
    problem primarily affects multi-byte and unicode character
    sets. (Bug#45803: http://bugs.mysql.com/45803)

  * Invalid memory reads and writes were generated when altering
    merge and base tables. This could lead to a crash or Valgrind
    errors:
    ==28038== Invalid write of size 1
    at: memset (mc_replace_strmem.c:479)
    by: myrg_attach_children (myrg_open.c:433)
    by: ha_myisammrg::attach_children() (ha_myisammrg.cc:546)
    by: ha_myisammrg::extra(ha_extra_function) (ha_myisammrg.cc:944)
    by: attach_merge_children(TABLE_LIST*) (sql_base.cc:4147)
    by: open_tables(THD*, TABLE_LIST**, unsigned*, unsigned) (sql_base.cc
    :4709)
    by: open_and_lock_tables_derived(THD*, TABLE_LIST*, bool) (sql_base.c
    c:4977)
    by: open_n_lock_single_table (mysql_priv.h:1550)
    by: mysql_alter_table(sql_table.cc:6428)
    by: mysql_execute_command(THD*) (sql_parse.cc:2860)
    by: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse
    .cc:5933)
    by: dispatch_command (sql_parse.cc:1213)
    (Bug#45796: http://bugs.mysql.com/45796)

  * Inserting data into a table using the macce character set with
    the IBMDB2I storage engine would fail.
    (Bug#45793: http://bugs.mysql.com/45793)

  * There was a race condition when changing
    innodb_commit_concurrency at runtime to the value DEFAULT.
    (Bug#45749: http://bugs.mysql.com/45749)
    See also Bug#42101: http://bugs.mysql.com/42101.

  * Performing an empty XA transaction caused the server to crash
    for the next XA transaction.
    (Bug#45548: http://bugs.mysql.com/45548)

  * For replication of a stored procedure that uses the gbk
    character set, the result on the master and slave differed.
    (Bug#45485: http://bugs.mysql.com/45485)

  * SHOW CREATE TRIGGER requires the TRIGGER privilege but was not
    checking privileges. (Bug#45412: http://bugs.mysql.com/45412)

  * An assertion failure could occur if InnoDB tried to unlock a
    record when the clustered index record was unknown.
    (Bug#45357: http://bugs.mysql.com/45357)

  * Bug#19027: http://bugs.mysql.com/19027 caused
    --enable-plugin_name (for example, --enable-innodb) not to
    work. (Bug#45336: http://bugs.mysql.com/45336)

  * If autocommit was enabled, InnoDB did not roll back DELETE or
    UPDATE statements if the statement was killed.
    (Bug#45309: http://bugs.mysql.com/45309)

  * Use of DECIMAL constants with more than 65 digits in CREATE
    TABLE ... SELECT statements led to spurious errors or
    assertion failures. (Bug#45262: http://bugs.mysql.com/45262)

  * The mysql client could misinterpret some character sequences
    as commands under some circumstances.
    (Bug#45236: http://bugs.mysql.com/45236)

  * Use of CONVERT() with an empty SET value could cause an
    assertion failure. (Bug#45168: http://bugs.mysql.com/45168)

  * InnoDB recovery could hang due to redo logging of doublewrite
    buffer pages. (Bug#45097: http://bugs.mysql.com/45097)

  * when reading binary data, the concatenation function for
    geometry data collections did not rigorously check for
    available data, leading to invalid reads and server crashes.
    (Bug#44684: http://bugs.mysql.com/44684)

  * If an error occurred during the creation of a table (for
    example, the table already existed) having an AUTO_INCREMENT
    column and a BEFORE trigger that used the INSERT ... SELECT
    construct, an internal flag was not reset properly. This led
    to a crash the next time that the table was opened again.
    (Bug#44653: http://bugs.mysql.com/44653)

  * For queries with a sufficient number of subqueries in the FROM
    clause of this form:
    SELECT * FROM (SELECT 1) AS t1,
                  (SELECT 2) AS t2,
                  (SELECT 3) AS t3, ...
    The query failed with a Too high level of nesting for select
    error, as though the query had this form:
    SELECT * FROM (SELECT 1 FROM (SELECT 2 FROM (SELECT 3 FROM ...
    (Bug#44156: http://bugs.mysql.com/44156)

  * configure.in contained references to literal instances of nm
    and libc, rather than to variables parameterized for the
    proper values on the current platform.
    (Bug#42721: http://bugs.mysql.com/42721)

  * configure.in did not properly check for the
    pthread_setschedprio() function.
    (Bug#42599: http://bugs.mysql.com/42599)

  * A workaround for a Sun Studio bug was instituted.
    (Bug#41710: http://bugs.mysql.com/41710)

  * Valgrind warnings that occurred for SHOW TABLE STATUS with
    InnoDB tables were silenced.
    (Bug#38479: http://bugs.mysql.com/38479)

  * In the mysql client, if the server connection was lost during
    repeated status commands, the client would fail to detect this
    and command output would be inconsistent.
    (Bug#37274: http://bugs.mysql.com/37274)

  * When invoked to start multiple server instances, mysqld_multi
    sometimes would fail to start them all due to not changing
    location into the base directory for each instance.
    (Bug#36654: http://bugs.mysql.com/36654)

  * Renaming a column that appeared in a foreign key definition
    did not update the foreign key definition with the new column
    name. (Bug#21704: http://bugs.mysql.com/21704)

=======================================================================

   Functionality added or changed:

     * Important Change: Replication: Previously, incident log
       events were represented as comments in the output from
       mysqlbinlog, making them effectively silent when playing
       back the binlog.
       (An incident log event represents an incident that could
       cause the contents of the database to change without that
       event being recorded in the binary log.)
       This meant that, if the SQL were applied to a server, it
       could potentially lead to the master and the slave having
       different data.  To make it possible to handle incident
       log events without breaking applications that expect the
       previous behavior, the nonsense statement RELOAD DATABASE
       is added to the SQL output for that incident log event,
       which causes an error.
       To use this functionality currently requires hand editing
       of the dump file and handling of each case on an
       individual basis by a database administrator before
       applying the output to a server.
       (Bug#44442: http://bugs.mysql.com/44442)

     * The time zone tables for Windows available at
       timezones.html have been updated.
       (Bug#39923: http://bugs.mysql.com/39923)

     * The mysqltest program now has a move_file from_file
       to_file command for renaming files.  This should be used
       in test cases rather than invoking an external command
       that might be platform specific.
       (Bug#39542: http://bugs.mysql.com/39542)

   Bugs fixed:

     * Incompatible Change: The server can load plugins under
       the control of startup options.  For example, many storage
       engines can be built in pluggable form and loaded when
       the server starts.  In the following descriptions,
       plugin_name stands for a plugin name such as innodb.
       Previously, plugin options were handled like other
       boolean options (see Section 4.2.3.2, "Program Option
       Modifiers").  That is, any of these options enabled the
       plugin:

          --plugin_name
          --plugin_name=1
          --enable-plugin_name

       And these options disabled the plugin:

          --plugin_name=0
          --disable-plugin_name
          --skip-plugin_name

       However, use of a boolean option for plugin loading did
       not provide control over what to do if the plugin failed
       to start properly: Should the server exit, or start with
       the plugin disabled? The actual behavior has been that
       the server starts with the plugin disabled, which can be
       problematic.  For example, if InnoDB fails to start,
       existing InnoDB tables become inaccessible, and attempts
       to create new InnoDB tables result in tables that use the
       default storage engine unless the NO_ENGINE_SUBSTITUTION
       SQL mode has been enabled to cause an error to occur
       instead.
       Now, there is a change in the options used to control
       plugin loading, such that they have a tristate format:

          + --plugin_name=OFF
            Do not enable the plugin.

          + --plugin_name[=ON]
            Enable the plugin.  If plugin initialization fails,
            start the server anyway, but with the plugin
            disabled.  Specifying the option as --plugin_name
            without a value also enables the plugin.

          + --plugin_name=FORCE
            Enable the plugin.  If plugin initialization fails,
            do not start the server.  In other words, force the
            server to run with the plugin or not at all.

       The values OFF, ON, and FORCE are not case sensitive.
       Suppose that CSV and InnoDB have been built as pluggable
       storage engines and that you want the server to load them
       at startup, subject to these conditions: The server is
       allowed to run if CSV initialization fails, but must
       require that InnoDB initialization succeed.  To accomplish
       that, use these lines in an option file:

          [mysqld]
          csv=ON
          innodb=FORCE

       This change is incompatible with the previous
       implementation if you used options of the form
       --plugin_name=0 or --plugin_name=1, which should be
       changed to --plugin_name=OFF or --plugin_name=ON,
       respectively.
       --enable-plugin_name is still supported and is the same
       as --plugin_name=ON. --disable-plugin_name and
       --skip-plugin_name are still supported and are the same
       as --plugin_name=OFF.
       (Bug#19027: http://bugs.mysql.com/19027)

     * Replication: When using row-based logging, the length of
       an event for which the field metadata exceeded 255 bytes
       in size was incorrectly calculated.  This could lead to
       corruption of the binary log, or cause the server to
       hang. (Bug#42749: http://bugs.mysql.com/42749)
       See also Bug#44548: http://bugs.mysql.com/44548,
       Bug#44672: http://bugs.mysql.com/44672,
       Bug#44752: http://bugs.mysql.com/44752.

     * Replication: The warning Statement is not safe to log in
       statement format, issued in situations when it cannot be
       determined that a statement or other database event can
       be written reliably to the binary log using the
       statement-based format, has been changed to Statement may
       not be safe to log in statement format.
       (Bug#42415: http://bugs.mysql.com/42415)

     * Replication: When stopping and restarting the slave while
       it was replicating temporary tables, the slave server
       could crash or raise an assertion failure.  This was due
       to the fact that, although temporary tables were saved
       between slave thread restarts, the reference to the
       thread being used (table->in_use) was not being properly
       updated when restarting, continuing to reference the old
       thread instead of the new one.  This issue affected
       statement-based replication only.
       (Bug#41725: http://bugs.mysql.com/41725)

     * ALTER TABLE on a view crashed the server.
       (Bug#44860: http://bugs.mysql.com/44860)

     * UNCOMPRESSED_LENGTH() returned a garbage result when
       passed a string shorter than 5 bytes.  Now
       UNCOMPRESSED_LENGTH() returns NULL and generates a
       warning. (Bug#44796: http://bugs.mysql.com/44796)

     * Several Valgrind warnings were silenced.
       (Bug#44774: http://bugs.mysql.com/44774,
       Bug#44792: http://bugs.mysql.com/44792)

     * Selecting RAND(N) function where N is a column of a
       constant table (table with a single row) failed with a
       SIGFPE signal. (Bug#44768: http://bugs.mysql.com/44768)

     * Conversion of a string to a different character set could
       use the same buffer for input and output, leading to
       incorrect results or warnings.
       (Bug#44743: http://bugs.mysql.com/44743,
       Bug#44766: http://bugs.mysql.com/44766)

     * mysqld_safe could fail to find the logger program.
       (Bug#44736: http://bugs.mysql.com/44736)

     * A Valgrind warning related to transaction processing was
       silenced. (Bug#44664: http://bugs.mysql.com/44664)

     * innochecksum could incorrectly determine the input file
       name from the arguments.
       (Bug#44484: http://bugs.mysql.com/44484)

     * Incorrect time was reported at the end of mysqldump
       output. (Bug#44424: http://bugs.mysql.com/44424)

     * Caching of GROUP BY expressions could lead to mismatches
       between compile-time and runtime calculations and cause a
       server crash. (Bug#44399: http://bugs.mysql.com/44399)

     * Lettercase conversion in multibyte cp932 or sjis
       character sequences could produce incorrect results.
       (Bug#44352: http://bugs.mysql.com/44352)

     * InnoDB was missing DB_ROLL_PTR information in Table
       Monitor COLUMNS output.
       (Bug#44320: http://bugs.mysql.com/44320)

     * Assertion failure could occur for duplicate-key errors in
       INSERT INTO ... SELECT statements.
       (Bug#44306: http://bugs.mysql.com/44306)

     * On 64-bit Windows systems, myisamchk did not handle
       key_buffer_size values larger than 4GB.
       (Bug#43940: http://bugs.mysql.com/43940)

     * EXPLAIN EXTENDED could crash for UNION queries in which
       the last SELECT was not parenthesized and included an
       ORDER BY clause. (Bug#43612: http://bugs.mysql.com/43612)

     * Multiple-table updates for InnoDB tables could produce
       incorrect results.
       (Bug#43580: http://bugs.mysql.com/43580)

     * For DELETE statements with ORDER BY var, where var was a
       global system variable with a NULL value, the server
       could crash. (Bug#42778: http://bugs.mysql.com/42778)

     * Builds linked against OpenSSL had a memory leak in
       association with use of X509 certificates.
       (Bug#42158: http://bugs.mysql.com/42158)

     * There was a race condition when changing
       innodb_commit_concurrency at runtime from zero to nonzero
       or from nonzero to zero.  Now this variable cannot be
       changed at runtime from zero to nonzero or vice versa.
       The value can still be changed from one nonzero value to
       another. (Bug#42101: http://bugs.mysql.com/42101)

     * SELECT ... INTO @var could produce values different from
       SELECT ... without the INTO clause.
       (Bug#42009: http://bugs.mysql.com/42009)

     * mysql_zap did not work on Mac OS X.
       (Bug#41883: http://bugs.mysql.com/41883)

     * For views created with a column list clause, column
       aliases were not substituted when selecting through the
       view using a HAVING clause.
       (Bug#40825: http://bugs.mysql.com/40825)

     * A multiple-table DELETE involving a table self-join could
       cause a server crash.
       (Bug#39918: http://bugs.mysql.com/39918)

     * Creating an InnoDB table with a comment containing a '#'
       character caused foreign key constraints to be omitted.
       (Bug#39793: http://bugs.mysql.com/39793)

     * The mysql option --ignore-spaces was nonfunctional.
       (Bug#39101: http://bugs.mysql.com/39101)

     * If a query was such as to produce the error 1054 Unknown
       column '...' in 'field list', using EXPLAIN EXTENDED with
       the query could cause a server crash.
       (Bug#37362: http://bugs.mysql.com/37362)

     * If the MYSQL_HISTFILE environment variable was set to
       /dev/null, the mysql client overwrote the /dev/null
       device file as a normal file.
       (Bug#34224: http://bugs.mysql.com/34224)

     * mysqld_safe mishandled certain parameters if they
       contained spaces.
       (Bug#33685: http://bugs.mysql.com/33685)

     * mysqladmin kill did not work for thread IDs larger than
       32 bits. (Bug#32457: http://bugs.mysql.com/32457)

     * Several client programs failed to interpret
       --skip-password as "send no password."
       (Bug#28479: http://bugs.mysql.com/28479)

     * Output from mysql --html did not encode the <, >, or &
       characters. (Bug#27884: http://bugs.mysql.com/27884)

     * mysql_convert_table_format did not prevent converting
       tables to MEMORY or BLACKHOLE tables, which could result
       in data loss. (Bug#27149: http://bugs.mysql.com/27149)