← Back to team overview

ius-coredev team mailing list archive

[Bug 1117674] Re: WL: mysql56

 

This is slightly complicated by upstream/Fedora's decision to (likely)
replace MySQL with MariaDB:

http://lists.fedoraproject.org/pipermail/devel/2013-January/176584.html

And it doesn't seem likely a mysql-5.6 package will hit rawhide in the
short term:

http://lists.fedoraproject.org/pipermail/devel/2013-February/178190.html

However, it would still be great to see at least an EL6 mysql56 package
in IUS.

EL5 would be great too, as my $dayjob still has a large number of mysql
deployments on that platform.   However, 5.6 requires at least openSSL
1.0.1 and YaSSL (WITH_SSL=bundled) is problematic for compatibility, so
it's understandble if this does not come to fruition.

-- 
You received this bug notification because you are a member of IUS Core
Development, which is subscribed to IUS Community Project.
https://bugs.launchpad.net/bugs/1117674

Title:
  WL: mysql56

Status in IUS Community Project:
  New

Bug description:
  Dear MySQL users,

  MySQL Server 5.6.10 (GA) is a new version of the world's most popular
  open source database. This is the first official release of MySQL 5.6.

  The new features in this release are now deemed to be of Release
  quality.

  Note that 5.6.10 includes all features in MySQL 5.5 and previous 5.6
  Development Milestone Releases. An overview of what's new in MySQL 5.6
  is available online at

  http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html

  For information on installing MySQL 5.6.10 on new servers, please see the
  MySQL installation documentation at

  http://dev.mysql.com/doc/refman/5.6/en/installing.html

  For upgrading from previous MySQL releases, please see the important
  upgrade considerations at

  http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-
  series.html

  MySQL Server 5.6.10 is available in source and binary form for a number
  of platforms from our download pages at

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

  Please note that the list of platforms for MySQL 5.6 has been adapted to
  the changes in the field:
  - Apple Mac OS X 10.6 and 10.7 on x86 (32 bit) and x86_64
  (Binary packages of MySQL 5.6 are not provided for OS X 10.5),
  - Debian 6 on x86 (32 bit) and x86_64
  (Binary packages of MySQL 5.6 are not provided for Debian 5),
  - RedHat Enterprise / Oracle Linux 5 and 6 on x86 (32 bit) and x86_64
  (Binary packages of MySQL 5.6 are not provided for RHEL/OL 4),
  - SuSE Enterprise Linux 11 on x86_64
  (Binary packages of MySQL 5.6 are not provided for SLES 10),
  - generic Linux (kernel 2.6) on x86 (32 bit) and x86_64,
  using glibc 2.5 (or newer),
  - FreeBSD 9 on x86_64
  (Binary packages of MySQL 5.6 are not provided for FreeBSD 7 and 8),
  - Oracle Solaris 10 and 11 on Sparc (64 bit), x86 (32 bit) and x86_64,
  - Windows Vista, 7, 8, Server 2008 on x86 (32 bit) and x86_64,
    Server 2008 R2 and Server 2012 on x86_64 only.
  (Binary packages of MySQL 5.6 are not provided for Windows XP and
  2003).

  This does not affect the list of supported platforms for 5.1 and 5.5.

  For Linux, the dependency on glibc 2.5 is new with 5.6, it is
  reflected in the names of the binary packages for generic Linux:
  "linux-glibc2.5" (former: "linux2.6").
  All supported specific platforms (RedHat 5 and newer, SuSE 11, ...) are
  using glibc 2.5 or newer.
  If you want to check your system, you may simply "run" the library:
  | Prompt$ /lib/libc.so.6
  | GNU C Library stable release version 2.7, by Roland McGrath et al.
  | Copyright (C) 2007 Free Software Foundation, Inc.
  | ...
  The above example was done on Debian 6, it shows glibc 2.7.

  Packages for specific Linux distributions are provided in the specific
  format (RPM or deb), in addition the generic tar.gz packages will fit
  these distributions.
  For RedHat-alike distributions like CentOS or Fedora, both the RedHat
  and the generic packages should work.
  If you are using a newer version of your operating system, its binary
  compatibility approach (supporting applications built for older
  versions) should ensure you can use MySQL 5.6.

  Windows packages are now available via the new Installer for Windows
  Installer or .ZIP (no-install) packages for more advanced needs. It
  should be noted that the previous MSI packaging is no longer available
  and the point and click configuration wizards and all MySQL products
  are now available in the unified Installer for Windows:

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

  The list of all "Bugs Fixed" for 5.6.10 may also be viewed online at

  http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-10.html

  If you are running a MySQL production level system, we would like to
  direct your attention to MySQL Enterprise Edition, which includes the
  most comprehensive set of MySQL production, backup, monitoring,
  modeling, development, and administration and migration tools so
  businesses can achieve the highest levels of MySQL performance,
  security and uptime.

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

  More information is available here:

  http://dev.mysql.com/doc/refman/5.6/en/mysql-enterprise.html

  On behalf of the MySQL release Engineering Team,

  - Bjorn Munch

  Enjoy!

  -----------------------------------------
  Changes in MySQL 5.6.10 (5 February 2013)

     Beginning with MySQL 5.6.10, MySQL Enterprise Edition is available
     for MySQL 5.6. Specifically, MySQL Enterprise 5.6.10 includes
     these components previously available only in MySQL 5.5: MySQL
     Enterprise Security (PAM and Windows authentication plugins),
     MySQL Enterprise Audit, and MySQL Thread Pool. For information
     about these features, see MySQL Enterprise Edition
     ( http://dev.mysql.com/doc/refman/5.6/en/mysql-enterprise.html ).
     To learn more about commercial products, see
     http://www.mysql.com/products/ .

     Known limitations of this release:

     On Microsoft Windows, when using the MySQL Installer to install
     MySQL Server 5.6.10 on a host with an existing MySQL Server of a
     different version (such as 5.5.30), that also has a different
     license (community versus commercial), you must first update the
     license type of the existing MySQL Server. Otherwise, MySQL
     Installer will remove MySQL Server(s) with different licenses from
     the one you chose with MySQL Server 5.6.10.

     On Microsoft Windows 8, updating a community release to a
     commercial release requires you to manually restart the MySQL
     service after the update.

     Functionality Added or Changed

       * Replication: An Auto_Position column has been added to the
         output generated by SHOW SLAVE STATUS. The value of this
         column shows whether replication autopositioning is in use. If
         autopositioning is enabled---that is, if MASTER_AUTO_POSITION
         = 1 was set by the last successful CHANGE MASTER TO statement
         that was executed on the slave---then the column's value is 1;
         if not, then the value is 0. (Bug #15992220)

       * In RPM packages built for Unbreakable Linux Network,
         libmysqld.so now has a version number. (Bug #15972480)

       * Error messages for ALTER TABLE statement using a LOCK or
         ALGORITHM value not supported for the given operation were
         very generic. The server now produces more informative
         messages. (Bug #15902911)

       * If a client with an expired password connected but
         old_passwords was not the value required to select the
         password hashing format appropriate for the client account,
         there was no way for the client to determine the proper value.
         Now the server automatically sets the session old_passwords
         value appropriately for the account password. (Bug #15892194)

       * The validate_password_policy_number system variable was
         renamed to validate_password_policy. (Bug #14588121)

       * In JSON-format EXPLAIN output, the attached_condition
         information for subqueries now includes select# to indicate
         the relative order of subquery execution. (Bug #13897507)

     Bugs Fixed

       * InnoDB; Performance: Optimized read operations for compressed
         (http://dev.mysql.com/doc/refman/5.6/en/glos_compression.html)
         tables by skipping redundant tests. The check for whether any
         related changes needed to be merged from the insert buffer
         (http://dev.mysql.com/doc/refman/5.6/en/glos_insert_buffer.htm
         l) was being called more often than necessary. (Bug #14329288,
         Bug #65886)

       * InnoDB; Performance: Immediately after a table was created,
         queries against it would not use loose index scans
         (http://dev.mysql.com/doc/refman/5.6/en/loose-index-scan.html)
         . The issue went away following an ALTER TABLE on the table.
         The fix improves the accuracy of the index statistics
         (http://dev.mysql.com/doc/refman/5.6/en/glos_index_statistics.
         html) gathered when the table is first created. (Bug
         #14200010)

       * Replication; Important Change: The lettercasing used for
         displaying UUIDs in global transaction identifiers was
         inconsistent. Now, all GTID values use lowercase, including
         those shown in the Retrieved_Gtid_Set and Executed_Gtid_Set
         columns from the output of SHOW SLAVE STATUS. (Bug #15869441)

       * InnoDB: Under certain circumstances, an InnoDB table was
         reported as corrupted after import using ALTER TABLE ...
         IMPORT TABLESPACE. The problem was accompanied by one of these
         messages:
  Warning  : InnoDB: The B-tree of index "PRIMARY" is corrupted.
  error    : Corrupt
         or:
  Warning  : InnoDB: The B-tree of index "GEN_CLUST_INDEX" is corrupted
  .
  error    : Corrupt
         This issue occurred intermittently, and primarily affected
         large tables. The REPAIR TABLE statement would fix the problem
         reported by the error message. (Bug #15960850, Bug #67807)

       * InnoDB: Some Valgrind warnings were issued during shutdown,
         while cleaning up a background thread that handles
         optimization of tables containing FULLTEXT indexes. (Bug
         #15994393)

       * InnoDB: If an online DDL operation to add a unique index
         failed, because duplicate items were created by concurrent DML
         during the online DDL operation, the ALTER TABLE operation
         failed with the wrong error type. It returned
         ER_INDEX_CORRUPT; now it returns the new error code
         ER_DUP_UNKNOWN_IN_INDEX. (It does not return ER_DUP_KEY,
         because the duplicate key value is not available to be
         reported when this condition occurs.) (Bug #15920713)

       * InnoDB: ALTER TABLE statements using the online DDL
         (http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
         feature could cause Valgrind warnings. (Bug #15933178)

       * InnoDB: Names of indexes being created by an online DDL
         (http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
         operation were being displayed incorrectly in
         information_schema tables while the operation was in progress.
         This fix ensures the table names have the leading 0xff byte
         stripped off for information_schema queries. This change
         affects the columns:

            + innodb_buffer_page.index_name

            + innodb_buffer_page_lru.index_name

            + innodb_cmp_per_index.index_name

            + innodb_cmp_per_index_reset.index_name

            + innodb_locks.lock_index

            + innodb_sys_indexes.name
         (Bug #15946256)

       * InnoDB: The status variable
         Innodb_buffer_pool_read_ahead_evicted could show an inaccurate
         value, higher than expected, because some pages in the buffer
         pool
         (http://dev.mysql.com/doc/refman/5.6/en/glos_buffer_pool.html)
         were incorrectly considered as being brought in by read-ahead
         (http://dev.mysql.com/doc/refman/5.6/en/glos_read_ahead.html)
         requests. (Bug #15859402, Bug #67476)

       * InnoDB: Creating an index on a CHAR column could fail for a
         table with a character set with varying length, such as UTF-8,
         if the table was created with the ROW_FORMAT=REDUNDANT clause.
         (Bug #15874001)

       * InnoDB: If the server crashed near the end of an online DDL
         (http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
         ALTER TABLE statement, a subsequent CHECK TABLE statement
         using the EXTENDED clause could cause a serious error. (Bug
         #15878013)

       * InnoDB: Specifying an innodb_log_file_size value of 4GB or
         larger was not possible on 64-bit Windows systems. This issue
         only affected debug builds. (Bug #15882860)

       * InnoDB: This fix ensures that in case of a serious unhandled
         error during an ALTER TABLE operation that copies the original
         table, any data that could be needed for data recovery is
         preserved, in tables using names of the form #sql-ib-table_id
         or #mysql50##sql-ib-table_id. (Bug #15866623)

       * InnoDB: An online DDL
         (http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
         operation to add a primary key
         (http://dev.mysql.com/doc/refman/5.6/en/glos_primary_key.html)
         to a table could encounter a serious error if the table also
         had an index on a column prefix
         (http://dev.mysql.com/doc/refman/5.6/en/glos_column_prefix.htm
         l) of a BLOB column.
         This fix suspends the background purge
         (http://dev.mysql.com/doc/refman/5.6/en/glos_purge.html)
         operation while a table is being rebuilt by an ALTER TABLE
         statement, if any rows containing off-page columns
         (http://dev.mysql.com/doc/refman/5.6/en/glos_off_page_column.h
         tml) would be removed. Currently, to avoid excessive space
         usage during the online DDL operation, avoid these types of
         concurrent DML
         (http://dev.mysql.com/doc/refman/5.6/en/glos_dml.html)
         operations until the ALTER TABLE is finished:

            + DELETE of rows that contain off-page columns.

            + UPDATE of primary key columns in rows that contain
              off-page columns.

            + UPDATE of off-page columns.
         (Bug #14827736)

       * InnoDB: The server could halt with an assertion error while
         creating an index:
  InnoDB: Assertion failure in thread thread_num in file row0merge.cc l
  ine 465
         This issue affected tables with a combination of
         ROW_FORMAT=REDUNDANT off-page columns
         (http://dev.mysql.com/doc/refman/5.6/en/glos_off_page_column.h
         tml), and an index on a column prefix
         (http://dev.mysql.com/doc/refman/5.6/en/glos_column_prefix.htm
         l). (Bug #14753402)

       * InnoDB: information_schema tables with InnoDB metadata, such
         as innodb_sys_tablestats, displayed non-alphanumeric
         characters in the names of tables using an encoded format, for
         example with @0024 instead of $. (Bug #14550145)

       * InnoDB: With a large value for innodb_buffer_pool_size, and
         innodb_buffer_pool_instances set greater than 1, pages
         (http://dev.mysql.com/doc/refman/5.6/en/glos_page.html) were
         being incorrectly evicted
         (http://dev.mysql.com/doc/refman/5.6/en/glos_eviction.html)
         from the buffer pool
         (http://dev.mysql.com/doc/refman/5.6/en/glos_buffer_pool.html)
         . (Bug #14125092)

       * Partitioning: Partition pruning is now enabled for tables
         using a storage engine that provides automatic partitioning,
         such as the NDB storage engine, but which are explicitly
         partitioned. Previously, pruning was disabled for all tables
         using such a storage engine, whether or not the tables had
         explicitly defined partitions.
         In addition, as part of this fix, explicit partition selection
         is now disabled for tables using a storage engine (such as
         NDB) that provides automatic partitioning. (Bug #14827952)
         References: See also Bug #14672885.

       * Replication: When using GTID-based replication, and whenever a
         transaction was executed on the master but was not sent to the
         slave because the slave already had a transaction with that
         ID, semisynchrononous replication timed out. One case in which
         this could happen was during a failover operation where the
         new master started behind the new slave. (Bug #15985893)

       * Replication: An unnecessary flush to disk performed after
         every transaction when using FILE as the replication info
         repository type could degrade performance. Now this is done
         only when both data and relay log info is stored in
         (transactional) tables. (Bug #15980626)

       * Replication: Issuing START SLAVE UNTIL SQL_BEFORE_GTIDS =
         gtid_set, where gtid_set covered a large number (tens or
         hundreds of millions) of transactions, could cause the server
         to hang. (Bug #15968413)

       * Replication: When a slave was started using --skip-innodb and
         replication info file repositories (FILE being the default for
         both --relay-log-info-repository and
         --master-info-repository), replication was incorrectly
         stopped. However, if the slave is using file repositories and
         not currently migrating between info repositories, replication
         should be able to work without issues. Now the server ignores
         errors raised when trying to open table info repositories in
         such conditions.
         In addition, binary log initialization was not performed
         correctly when starting the slave with --skip-innodb, which
         caused the --log-bin option to be ignored. (Bug #15956714, Bug
         #67798, Bug #15971607)

       * Replication: When temporary and persistent tables, or
         temporary tables using different storage engines, are dropped
         in a single statement, this statement is actually written as
         two statements to the binary log, each represented by its own
         log event. When gtid_mode is ON, each DDL event must have a
         GTID; however, in such cases, the statement dropping the
         temporary table was uncommitted, which meant that it was not
         given its own GTID.
         Now, when a DDL statement dropping a temporary table and a
         table that is persistent, or that uses a different storage
         engine, is separated in the manner just described, and the
         resulting logged statement affecting only the temporary table
         does not implicitly commit, a commit is forced so that the
         corresponding log event has own unique GTID. (Bug #15947962)

       * Replication: When used on a binary log that had been written
         by a GTID-enabled server, mysqlbinlog did not correctly handle
         transactions left unclosed by the omission of statements that
         were ignored when the --database option was employed.
         Now, whenever mysqlbinlog --database reads a GTID log event,
         it checks to see whether there is an unclosed transaction, and
         if so, issues a commit. (Bug #15912728)

       * Replication: Semisynchronous replication did not work
         correctly with GTIDs enabled. (Bug #15927032)
         References: See also Bug #14737388.

       * Replication: When GTIDs were enabled, the automatic dropping
         of a temporary table when a client disconnected did not always
         generate a GTID. Now each logged DROP TABLE statement,
         including any generated by the server, is guaranteed to have
         its own GTID. (Bug #15907504)

       * Replication: After dropping a column from the slave's version
         of a table, then altering the same column of this table on the
         master (so that a type conversion would have been required had
         the column not been droppped on the slave), inserts into this
         table caused replication to fail. (Bug #15888454)

       * Replication: SET GLOBAL sql_slave_skip_counter = 1 did not
         skip errors or update the slave's position in the binary log
         position when using --gtid-mode = ON. (Bug #15833516)

       * Replication: When a binary log is replayed on a server (for
         example, by executing a command like mysqlbinlog binlog.000001
         | mysql), it sets a pseudo-slave mode on the client connection
         used, so that the server can read binlog and apply binary log
         events correctly. However, the pseudo-slave mode was not
         disabled after the binary log dump was read, which caused
         unexpected filtering rules to be applied to SQL statements
         subsequently executed on the same connection. (Bug #15891524)

       * Replication: During mysqld shutdown, global GTID variables
         were released before it was made certain that all plugins had
         stopped using them. (Bug #14798275)

       * Replication: MASTER_POS_WAIT() could hang or return -1 due to
         invalid updates by the slave SQL thread when transactions were
         skipped by the GTID protocol. (Bug #14737388)
         References: See also Bug #15927032.

       * Replication: Trying to execute a Stop event on a multithreaded
         slave could cause unwanted updates to the relay log, leading
         the slave to lose synchronization with the master. (Bug
         #14737388)

       * Replication: Names of databases in binary log query log events
         were not properly checked for length. (Bug #14636219)

       * Replication: Issuing START SLAVE concurrently with setting
         sql_slave_skip_counter or slave_net_timeout could cause a
         deadlock. (Bug #14236151)

       * Replication: When using statement-based replication, and where
         the master and the slave used table schemas having different
         AUTO_INCREMENT columns, inserts generating AUTO_INCREMENT
         values logged for a given table on the master could be applied
         to the wrong table on the slave. (Bug #12669186)

       * Replication: Repeated execution of CHANGE MASTER TO statements
         using invalid MASTER_LOG_POS values could lead to errors and
         possibly a crash on the slave. Now in such cases, the
         statement fails with a clear error message. (Bug #11764602,
         Bug #57454)

       * Microsoft Windows: Dynamic file names (with colons) are no
         longer allowed. Static file names using the Alternate Data
         Stream (ADS) NTFS functionality of Microsoft Windows may
         continue to be used. (Bug #11761752)

       * During client connection processing, the server now performs
         password-expiration checking after SSL checks. (Bug #16103348)

       * A buffer-handling problem in yaSSL was fixed. (Bug #15965288)

       * The plugin logging routine mishandled its argument, resulting
         in undefined behavior. (Bug #16002890)

       * An ALTER TABLE with the ADD PRIMARY KEY or ADD UNIQUE INDEX
         clause could encounter a serious error if the columns for the
         primary key
         (http://dev.mysql.com/doc/refman/5.6/en/glos_primary_key.html)
         or unique index
         (http://dev.mysql.com/doc/refman/5.6/en/glos_unique_index.html
         ) contained duplicate entries. This error occurred
         intermittently, depending on how the rows were physically
         distributed across index blocks. (Bug #15908291)

       * The ALTER TABLE statement can now use the LOCK=NONE clause,
         allowing online DDL
         (http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
         with concurrent DML
         (http://dev.mysql.com/doc/refman/5.6/en/glos_dml.html), for
         child tables
         (http://dev.mysql.com/doc/refman/5.6/en/glos_child_table.html)
         containing foreign key constraints
         (http://dev.mysql.com/doc/refman/5.6/en/glos_foreign_key_const
         raint.html). (Bug #15912214)

       * In certain rare cases, a query using UpdateXML() could cause
         the server to crash. (Bug #15948580)
         References: See also Bug #13007062.

       * AES_DECRYPT() and AES_ENCRYPT() had memory leaks when MySQL
         was compiled using OpenSSL. (Bug #15909183)

       * Several OpenSSL-related Valgrind warnings were corrected. (Bug
         #15908967)

       * Several OpenSSL-related memory leaks were fixed. (Bug
         #15921729)

       * Very long database names in queries could cause the server to
         exit. (Bug #15912213)

       * Within a stored procedure, executing a multiple-table DELETE
         statement that used a very long table alias could cause the
         server to exit. (Bug #15954896)

       * Very long table aliases in queries could cause the server to
         exit. (Bug #15948123)

       * Metadata locking and table definition cache routines did not
         always check length of names passed to them. (Bug #15954872)

       * A comment added to mysqldump output for the --set-gid-purged
         option was malformed and caused a syntax error when the dump
         file was reloaded. (Bug #15922502)
         References: See also Bug #14832472.

       * Contention in the thread pool during kill processing could
         lead to a Valgrind panic. (Bug #15921866)

       * In the absence of a FULLTEXT index on an InnoDB table, a
         full-text query with COUNT(*) could raise an assertion. (Bug
         #15950531)

       * If an error occurred during the final phase of an online DDL
         (http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
         operation, some cached metadata about the table might not be
         restored to its original state. This issue typically affected
         operations that renamed a column, and also dropped and
         re-created an index on that column, in the same ALTER TABLE
         statement. This issue did not affect operations that
         reorganize the clustered index
         (http://dev.mysql.com/doc/refman/5.6/en/glos_clustered_index.h
         tml) of the table, such as adding a new primary key. (Bug
         #15866734)

       * In debug builds, the server could not start on 64-bit Windows
         systems when a value of 16 GB or higher was specified for
         innodb_buffer_pool_size. Non-debug builds would likely have
         subtler issues, such as memory being allocated for the buffer
         pool
         (http://dev.mysql.com/doc/refman/5.6/en/glos_buffer_pool.html)
         but not used, or read requests overlooking pages already
         cached in the buffer pool.
         On 32-bit Windows systems, the value of
         innodb_buffer_pool_instances is increased if necessary so that
         no buffer pool instance is larger then 1.3 GB, due to system
         limitations on memory allocation. This automatic adjustment
         needed for 32-bit Windows systems was incorrectly applied to
         64-bit systems also; for systems with 16 GB or larger buffer
         pools, the adjusted value of innodb_buffer_pool_instances
         would exceed the upper limit of 64, causing an assertion error
         in debug builds. (Bug #15883071)

       * A heavy workload of online DDL
         (http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
         and concurrent DML
         (http://dev.mysql.com/doc/refman/5.6/en/glos_dml.html) on a
         table on a master
         (http://dev.mysql.com/doc/mysql-monitor/2.3/en/glossary.html#g
         los_master) server could cause errors as the changes were
         replicated to slave
         (http://dev.mysql.com/doc/mysql-monitor/2.3/en/glossary.html#g
         los_slave) servers. For example, processing a DROP COLUMN
         operation at the same time as queries referring to the dropped
         column could cause errors on slave servers if the statements
         finished in a different order than on the master. (Bug
         #15878880)

       * If the server shut down unexpectedly, the presence of an
         InnoDB table with 1018 columns (very close to the upper limit
         of 1020 columns) could cause an assertion error during server
         restart:
  InnoDB: Failing assertion: table->n_def == table->n_cols - 3
         (Bug #15834685)

       * The Performance Schema normally ignores temporary table
         events. User-defined temporary tables are truncated by being
         re-created, but the Performance Schema did not recognize
         re-created temporary tables as being temporary and raised an
         assertion. (Bug #15884836)

       * The Performance Schema session_connect_attrs table displayed
         extraneous information. (Bug #15864703)

       * Subqueries with COUNT(DISTINCT ...)) could cause the server to
         exit. (Bug #15832620)
         References: See also Bug #11750963.

       * Rows_log_event allocated one too few bytes for the row buffer.
         (Bug #15890178)

       * For the LooseScan semi-join strategy, the optimizer could rely
         on an uninitialized variable. (Bug #15849654)

       * For debug builds, an assertion could be raised when: 1) A view
         was based on a MEMORY table; 2) The table was altered to drop
         some column in use by the view; 3) A SELECT was done on the
         view with binary logging disabled. (Bug #15847447)

       * If loose index scan was used on a query with descending order,
         the result set contained NULL values instead of the correct
         values. (Bug #15848665)

       * The optimizer's cost-based choice between IN -> EXISTS
         subquery transformation and subquery materialization was
         sometimes incorrect if the IN predicate was OR-ed with some
         other predicate. (Bug #15866339)
         References: See also Bug #13111584.

       * In some cases, a cost value was printed to Optimizer Trace
         output without being initialized, resulting in incorrect
         output. (Bug #15877453)

       * Several code issues identified by Fortify were corrected. (Bug
         #15884324)

       * Some queries, if used as prepared statements, caused the
         server to exit if an error occurred. (Bug #15877062)

       * Complex IN subqueries could cause the server to exit. (Bug
         #15877738)

       * It was possible to expire the password for an account even if
         the account is authenticated by an authentication plugin that
         does not support password expiration. (Bug #15849009)

       * When the server reads the mysql.user table, it now checks for
         invalid native and old-native password hashes and ignores
         accounts with invalid hashes. (Bug #14845445)

       * The validate_password plugin did not check certain passwords.
         (Bug #14843970)

       * GRANT ... IDENTIFIED BY could fail to flush the privileges.
         (Bug #14849959)

       * Setting the validate_password_length system variable did not
         take into account that the minimum value is a function of
         several other related system variables. Now the server will
         not set the value less than the value of this expression:
  validate_password_number_count
  + validate_password_special_char_count
  + (2 * validate_password_mixed_case_count)
         (Bug #14850601)

       * When used with an XPath expression that contained the output
         of a stored function, ExtractValue() failed with the error
         Only constant XPATH queries are supported. (Bug #14798445, Bug
         #67313)

       * MySQL could encounter an error during shutdown on Windows XP
         or earlier systems. This issue did not affect systems running
         Windows Vista or higher, which use atomic condition variables
         to represent Windows Events. (Bug #14822849)

       * Temporary table creation during execution of
         INFORMATION_SCHEMA queries could result in Valgrind warnings.
         (Bug #14801497)

       * mysqladmin did not properly process commands for users with
         expired passwords. (Bug #14833621)

       * XA START had a race condition that could cause a server crash.
         (Bug #14729757)

       * The server could halt with an assertion error due to a
         recently added error code:
  InnoDB: unknown error code 1502
  InnoDB: Assertion failure in thread thread_num in file row0mysql.cc l
  ine 683
  mysqld got signal 6 ;
         Now, the server returns the error code DB_DICT_CHANGED to the
         client in this case. (Bug #14764015)

       * Queries that used grouping failed when executed using a cursor
         if the optimizer processed the grouping using a temporary
         table. (Bug #14740889)

       * The server could exit when the MyISAM storage engine (rather
         than MEMORY) was used to materialize a derived table. (Bug
         #14728469)

       * The sha256_password authentication plugin requires that the
         client connect either using SSL or have RSA enabled. When
         neither condition was met, an uninformative error message was
         produced. Now the error message is more informative. (Bug
         #14751925)

       * The server now logs warnings at startup if the file specified
         for the validate_password_dictionary_file system variable
         violates constraints on valid password file contents. (Bug
         #14588148)

       * At startup, some InnoDB boolean system variables could be set
         to 1 or 0, but not ON or OFF. These included
         innodb_file_per_table, innodb_force_load_corrupted, and
         innodb_large_prefix. (Bug #14494893)

       * Output generated with mysqldump --routines could produce
         syntax errors when reloaded. (Bug #14463669)

       * Calculations involving self-intersecting polygons caused an
         assertion to be raised. (Bug #14503584)

       * If ALTER TABLE was killed, the server could report
         ER_QUERY_INTERRUPTED even if the alterations had been made
         successfully. This is misleading to the user. Also, the
         statement would not be written to the binary log, leading to
         incorrect replication (Bug #14382643)

       * The parser failed to return an error for some invalid UNION
         constructs. (Bug #13992148)

       * Preloading of client plugins specified with the
         LIBMYSQL_PLUGINS environment variable could fail unless the
         plugins were located in the hardwired default plugin
         directory. The C API now checks during plugin preloading for a
         LIBMYSQL_PLUGIN_DIR environment variable which can be set to
         the path name of the directory in which to look for client
         plugins.
         In addition, for explicit client plugin loading, the
         mysql_load_plugin() and mysql_load_plugin_v() C API functions
         have been modified to use the LIBMYSQL_PLUGIN_DIR value if it
         exists and the --plugin-dir option was not given. If
         --plugin-dir is given, mysql_load_plugin() and
         mysql_load_plugin_v() ignore LIBMYSQL_PLUGIN_DIR. (Bug
         #13994567)

       * With the ONLY_FULL_GROUP_BY SQL mode enabled, executing a
         stored function twice that contains a SQL query that is not
         valid with that mode enabled caused the server to exit. (Bug
         #13996639)

       * Autosizing of Performance Schema parameters could result in
         settings that caused excessive CPU use. (Bug #67736, Bug
         #15927744)

       * The optimizer sometimes chose a nonoptimimal range scan
         strategy when a query included a LIMIT clause. (Bug #67432,
         Bug #15829358)

       * Full-text searches in InnoDB tables could return incorrect
         results. (Bug #67257, Bug #14771282)

       * The mysql client could mishandle the delimiter command if it
         occurred on a line during which mysql was looking for the end
         of a quoted string. (Bug #64135, Bug #13639125)

       * The Performance Schema normally ignores temporary table
         events, but sometimes failed to properly identify a table as
         temporary and consequently recorded events for the table. (Bug
         #67098, Bug #14756887)

       * Some messages written by the server to the error log referred
         to the deprecated --log-slow-queries option rather than the
         --slow-query-log option. Similarly, the server referred to the
         deprecated --log option rather than the --general-log-file and
         --log-output options. (Bug #67892, Bug #15996571)

       * Attempting to perform an in-place upgrade from MySQL 5.1 to
         5.6 causes the server to exit due to a mismatch between the
         privilege structures in the two series. (This is not a
         supported operation, but the server should not exit
         ungracefully.) (Bug #67319, Bug #14826854)

       * DECIMAL multiplication operations could produce significant
         inaccuracy. (Bug #45860, Bug #11754279)

       * Due to a thread race condition, the server could exit while
         attempting to read the Performance Schema
         threads.PROCESSLIST_INFO column. (Bug #68127, Bug #16196158)

       * The optimizer could choose an IN-to-EXISTS transformation for
         subquery execution in some cases when subquery materialization
         would be cheaper. (Bug #67511, Bug #15848521)

       * It is not permitted to use CREATE TABLE to create an NDB table
         with user-defined partitioning and a foreign key. However, it
         was possible to create an NDB table with a foreign key, then
         add partitioning to it using ALTER TABLE, thus creating a
         table which was impossible to backup/restore using mysqldump.
         Now the prohibition is enforced consistently. (Bug #67492, Bug
         #15844519)

       * For single-table DELETE or UPDATE statements, EXPLAIN
         displayed a type value of ALL (full-table scan access method)
         even if the optimizer chose to scan the table by an index
         access method. Now the type value is displayed as index. (Bug
         #67637, Bug #15892875)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ius/+bug/1117674/+subscriptions


References