MySQL 5.6 Release Notes
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 https://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.
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:
Innodb_buffer_pool_bytes_data
,
to supplement
Innodb_buffer_pool_pages_data
.
Innodb_buffer_pool_bytes_dirty
,
to supplement
Innodb_buffer_pool_pages_dirty
.
(Bug #15842637)
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:
There is a new
disconnect_on_expired_password
system variable (default: enabled). This controls how the
server treats expired-password accounts.
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
.
For more information about how the client-side flags interact
with
disconnect_on_expired_password
,
see Server Handling of Expired Passwords.
(Bug #67568, Bug #15874023)
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)
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)
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:
Adding or dropping a column.
Adding or dropping a primary key index.
Making a column NULL
or NOT
NULL
.
Reordering columns.
Changing the ROW_FORMAT
or
KEY_BLOCK_SIZE
properties.
(Bug #16095573, Bug #68019)
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:
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:
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_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:
ALTER TABLE
statements using the
online DDL feature could
cause Valgrind warnings.
(Bug #15933178)
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 DDL
ALTER 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 utf8
, 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-
or
table_id
#mysql50##sql-ib-
.
(Bug #15866623)table_id
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 were incorrectly considered as being brought in by
read-ahead requests.
(Bug #15859402, Bug #67476)
InnoDB:
An online DDL operation
to add a primary key to
a table could encounter a serious error if the table also had an
index on a column
prefix of a BLOB
column.
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:
(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 line 465
This issue affected tables with a combination of
ROW_FORMAT=REDUNDANT
off-page columns,
and an index on a column
prefix.
(Bug #14753402)
InnoDB: The server could halt with an assertion error when creating an index on a column prefix for a column using a multibyte character set:
InnoDB: Assertion failure in thread thread_num
in file row0merge.cc line 465
InnoDB: Failing assertion: len == ifield-<fixed_len
(Bug #14753402)
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)
InnoDB:
With a large value for
innodb_buffer_pool_size
, and
innodb_buffer_pool_instances
set greater than 1, pages were
being incorrectly evicted
from the buffer pool.
(Bug #14125092)
InnoDB:
Corruption of the
innodb_ft_user_stopword_table
table could
cause a server exit.
(Bug #67960, Bug #16038656)
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 =
, where
gtid_set
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 the
master_info_repository
and
relay_log_info_repository
system variables), 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 mysqlbinlog
binlog.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 #14775893)
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)
Oracle RPM packages were unusable by yum
due
to issues with the obsoletes
line in the
.spec
file causing yum
to interpret the package as obsoleting itself.
(Bug #16298542)
During client connection processing, the server now performs password-expiration checking after SSL checks. (Bug #16103348)
The plugin logging routine mishandled its argument, resulting in undefined behavior. (Bug #16002890)
A buffer-handling problem in yaSSL was fixed. (Bug #15965288)
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)
Metadata locking and table definition cache routines did not always check length of names passed to them. (Bug #15954872)
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)
Several OpenSSL-related memory leaks were fixed. (Bug #15921729)
The ALTER TABLE
statement can now
use the LOCK=NONE
clause, allowing
online DDL with
concurrent DML, for
child tables containing
foreign key
constraints.
(Bug #15912214)
Very long database names in queries could cause the server to exit. (Bug #15912213, Bug #16900358)
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)
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
than 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)
References: See also: Bug #13111584.
The session_connect_attrs
Performance Schema table displayed extraneous information.
(Bug #15864703)
For the LooseScan semijoin 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:
validate_password_number_count + validate_password_special_char_count + (2 * validate_password_mixed_case_count)
(Bug #14850601)
GRANT ... IDENTIFIED
BY
could fail to flush the privileges.
(Bug #14849959)
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:
InnoDB: unknown error code 1502
InnoDB: Assertion failure in thread thread_num
in file row0mysql.cc line 683
mysqld got signal 6 ;
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)
Calculations involving self-intersecting polygons caused an assertion to be raised. (Bug #14503584)
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)
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 an 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.
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, Bug #18110355)
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)
Autosizing of Performance Schema parameters could result in settings that caused excessive CPU use. (Bug #67736, Bug #15927744)
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)
Full-text searches in InnoDB
tables
could return incorrect results.
(Bug #67257, Bug #14771282)
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)
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)
DECIMAL
multiplication operations could
produce significant inaccuracy.
(Bug #45860, Bug #11754279)