Skip navigation links

MySQL Forums :: Announcements :: MySQL Community Server 5.6.10 (GA) has been released


Advanced Search

MySQL Community Server 5.6.10 (GA) has been released
Posted by: Bjørn Munch ()
Date: February 05, 2013 07:07AM

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

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)

Options: ReplyQuote


Subject Views Written By Posted
MySQL Community Server 5.6.10 (GA) has been released 3885 Bjørn Munch 02/05/2013 07:07AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.