Changes in MySQL 5.6.10 (2013-02-05, General Availability)

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. 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

InnoDB:
When compressed tables were used, the calculation to compute
memory usage within the buffer
pool was complex because the compressed pages could be
smaller than 16KB or the user-specified
page size. Although this
information can be retrieved from the
INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
table, that operation is expensive. The following new status
variables help to simplify calculations involving buffer pool
memory usage:

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 authentication method. For
example, if the account uses the
sha256_password authentication plugin, the
server sets old_passwords=2.
(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)

The following changes were made to the sandbox mode that the
server uses to handle client connections for accounts with
expired passwords:

Two flags were added to the C API client library:
MYSQL_OPT_CAN_HANDLE_EXPIRED_PASSWORDS
for mysql_options() and
CLIENT_CAN_HANDLE_EXPIRED_PASSWORDS for
mysql_real_connect(). Each flag enables a
client program to indicate whether it can handle sandbox
mode for accounts with expired passwords.

MYSQL_OPT_CAN_HANDLE_EXPIRED_PASSWORDS is
enabled for mysqltest unconditionally,
for mysql in interactive mode, and for
mysqladmin if the first command is
password.

Performance; InnoDB:
Some data structures related to undo logging could be
initialized unnecessarily during a query, although they were
only needed under specific conditions.
(Bug #14676084)

Performance; InnoDB:
Optimized read operations for
compressed tables by
skipping redundant tests. The check for whether any related
changes needed to be merged from the
insert buffer was
being called more often than necessary.
(Bug #14329288, Bug #65886)

Performance; InnoDB:
Immediately after a table was created, a query against it would
not use a loose index
scan. The same query might use a loose index scan
following an ALTER TABLE on the
table. The fix improves the accuracy of the cost estimate for
queries involving the grouping functions
min() and max(), and
prevents the query plan from being changed by the
ALTER TABLE statement. (The more
stable query plan might or might not use a loose index scan.)
(Bug #14200010)

Important Change; Replication:
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:
When the primary key of a table includes a column prefix, and a
full-text index is defined on the table, a full-text search
resulted in an unnecessary warning being written to the error
log. This fix suppresses the unnecessary warning.
(Bug #16169411)

InnoDB:
In online DDL operations,
a DROP FOREIGN KEY clause was not allowed in
an ALTER TABLE statement that
also performed any of the following:

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:
During an online DDL
operation, changing a column from nullable to NOT
NULL could succeed or fail differently depending on
whether the ALTER TABLE statement
used ALGORITHM=INPLACE or
ALGORITHM=COPY. An operation with
ALGORITHM=COPY would succeed even if the
column contained NULL values, while an
operation with ALGORITHM=INPLACE failed
because of the possibility that the column contained
NULL values. Now, making a column
NOT NULL in combination with the
ALGORITHM=INPLACE clause is allowed, but only
if the sql_mode configuration
option includes the
STRICT_TRANS_TABLES or
STRICT_ALL_TABLES setting. If
the ALGORITHM clause is not specified with
the ALTER TABLE statement, the
online DDL operation will use
ALGORITHM=INPLACE if possible, or
ALGORITHM=COPY if not.
(Bug #15961327)

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:

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:
Names of indexes being created by an
online DDL 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:
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:
During an online DDL
operation to add a unique
index, DML operations
that created duplicate values could fail with an
ER_DUP_KEY error even though the
index had not been made visible yet. (There was a brief time
window when this condition could occur.) The fix causes the
index creation operation to fail instead, if the index would be
invalid because of duplicate entries produced by concurrent DML.
(Bug #15920445)

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:
If the server crashed near the end of an
online DDLALTER TABLE statement, a
subsequent CHECK TABLE statement
using the EXTENDED clause could cause a
serious error.
(Bug #15878013)

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

This fix suspends the background
purge operation while a table
is being rebuilt by an ALTER
TABLE statement, if any rows containing
off-page columns
would be removed. Currently, to avoid excessive space usage
during the online DDL operation, avoid these types of concurrent
DML operations until the
ALTER TABLE is finished:

InnoDB:
A regression introduced by the fix for Bug#14100254 would result
in a “!BPAGE->FILE_PAGE_WAS_FREED” assertion.
(Bug #14676249)

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

InnoDB:
If the value of
innodb_force_recovery was less
than 6, opening a corrupted table might loop forever if a
corrupted page was read when calculating statistics for the
table. Information about the corrupted page was written
repeatedly to the error log, possibly causing a disk space
issue. The fix causes the server to halt after a fixed number of
failed attempts to read the page. To troubleshoot such a
corruption issue, set
innodb_force_recovery=6 and
restart.
(Bug #14147491, Bug #65469)

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:
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:
Semisynchronous replication did not work correctly with GTIDs
enabled.
(Bug #15927032)

References: See also Bug #14737388.

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:
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:
When a binary log is replayed on a server (for example, by
executing a command like mysqlbinlogbinlog.000001|mysql), it sets a pseudo-slave mode on the
client connection used, so that the server can read binary log
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:
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:
Use of sql_slave_skip_counter
is not compatible with GTID-based replication. Setting this
variable to a nonzero value is now disallowed whenever
--gtid-mode = ON, and attempting
to do so fails with an error.
(Bug #15833516)

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 multi-threaded slave could
cause unwanted updates to the relay log, leading the slave to
lose synchronization with the master.
(Bug #14737388)

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)

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

In certain rare cases, a query using
UpdateXML() could cause the
server to crash.
(Bug #15948580)

References: See also Bug #13007062.

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

An online DDL operation that dropped an index could proceed
despite not having sufficient locks on the table. This issue
could cause a serious error, although the error was only
observed in debug builds.
(Bug #15936065)

A comment added to mysqldump output for the
--set-gtid-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)

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 or unique
index contained duplicate entries. This error occurred
intermittently, depending on how the rows were physically
distributed across index blocks.
(Bug #15908291)

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

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)

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

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 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 and concurrent DML on
a table on a master
server could cause errors as the changes were replicated
to 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)

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

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

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

If an error occurred during the final phase of an
online DDL 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 of
the table, such as adding a new primary key.
(Bug #15866734)

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)

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

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)

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)

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

Subqueries with COUNT(DISTINCT ...)) could
cause the server to exit.
(Bug #15832620)

References: See also Bug #11750963.

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:

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)

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

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)

An issue with locking order for the system tables and the InnoDB
data dictionary
could lead to an internal deadlock within MySQL.
(Bug #14805484)

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

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)

The server could halt with an assertion error due to a recently
added error code:

Now, the server returns the error code
DB_DICT_CHANGED to the client in this case.
(Bug #14764015)

The clause ALGORITHM=INPLACE clause in an
ALTER TABLE statement for a
partitioned table could lead to consistency issues if a crash
occurred while changes were applied to some of the underlying
tables but not all. This fix prohibits the
ALGORITHM=INPLACE clause for DDL operations
on partitioned tables.
(Bug #14760210)

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)

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

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

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

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)

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)

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)

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.

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

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)

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)

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)

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 back up or restore using
mysqldump. Now the prohibition is enforced
consistently.
(Bug #67492, Bug #15844519)

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

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)

mysqldump could fail to dump all tables in
the mysql database.
(Bug #67261, Bug #14771252)