MySQL 5.7 Release Notes
This is a milestone release, for use at your own risk. Upgrades between milestone releases (or from a milestone release to a GA release) are not supported. Significant development changes take place in milestone releases and you may encounter compatibility issues, such as data format changes that require attention in addition to the usual procedure of running mysql_upgrade. For example, you may find it necessary to dump your data with mysqldump before the upgrade and reload it afterward. (Making a backup before the upgrade is a prudent precaution in any case.)
Several changes were made to the audit log plugin for better compatibility with Oracle Audit Vault.
The format of the audit log file has changed:
Information within <AUDIT_RECORD>
elements written in the old format using attributes is
written in the new format using subelements.
The new format includes more information in
<AUDIT_RECORD>
elements. Every
element includes a RECORD_ID
value
providing a unique identifier. The
TIMESTAMP
value includes time zone
information. Query records include HOST
,
IP
, OS_LOGIN
, and
USER
information, as well as
COMMAND_CLASS
and
STATUS_CODE
values.
The STATUS_CODE
value differs from the
existing STATUS
value:
STATUS_CODE
is 0 for success and 1 for
error, which is compatible with the EZ_collector consumer
for Audit Vault. STATUS
is the value of
the mysql_errno()
C API
function. This is 0 for success and nonzero for error, and
thus is not necessarily 1 for error.
Example of old <AUDIT_RECORD>
format:
<AUDIT_RECORD TIMESTAMP="2013-04-15T15:27:27" NAME="Query" CONNECTION_ID="3" STATUS="0" SQLTEXT="SELECT 1"/>
Example of new <AUDIT_RECORD>
format:
<AUDIT_RECORD> <TIMESTAMP>2013-04-15T15:27:27 UTC</TIMESTAMP> <RECORD_ID>3998_2013-04-15T15:27:27</RECORD_ID> <NAME>Query</NAME> <CONNECTION_ID>3</CONNECTION_ID> <STATUS>0</STATUS> <STATUS_CODE>0</STATUS_CODE> <USER>root[root] @ localhost [127.0.0.1]</USER> <OS_LOGIN></OS_LOGIN> <HOST>localhost</HOST> <IP>127.0.0.1</IP> <COMMAND_CLASS>select</COMMAND_CLASS> <SQLTEXT>SELECT 1</SQLTEXT> </AUDIT_RECORD>
When the audit log plugin rotates the audit log file, it uses a
different file name format. For a log file named
audit.log
, the plugin previously renamed
the file to
audit.log.
.
The plugin now renames the file to
TIMESTAMP
audit.log.
to indicate that it is an XML file.
TIMESTAMP
.xml
For information about the audit log plugin, see MySQL Enterprise Audit.
If you previously used an older version of the audit log plugin, use this procedure to avoid writing new-format log entries to an existing log file that contains old-format entries:
Stop the server.
Rename the current audit log file manually. This file will contain only old-format log entries.
Update the server and restart it. The audit log plugin will create a new log file, which will contain only new-format log entries.
The API for writing audit plugins has also changed. The
mysql_event_general
structure has new members
to represent client host name and IP address, command class, and
external user. For more information, see
Writing Audit Plugins.
(WL #6715)
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, WL #6587)
The deprecated innodb_mirrored_log_groups
system variable has been removed.
(WL #6808)
Incompatible Change:
SHOW ENGINE
PERFORMANCE_SCHEMA STATUS
output used a mix of
row_count
and count
attributes. These are now all count
.
Similarly, the output used a mix of row_size
and size
attributes. These are now all
size
.
(Bug #16165468)
Performance: String hashing overhead was reduced. This also improves performance for metadata locking, the table definition cache, and Performance Schema table I/O and file I/O instrumentation. (Bug #13944392)
InnoDB:
Non-compressed, user-created InnoDB
temporary
tables and on-disk internal InnoDB
temporary
tables are now created in a shared temporary tablespace. The
innodb_temp_data_file_path
configuration option defines the relative path, name, size, and
attributes for temporary tablespace data files. If no value is
specified for
innodb_temp_data_file_path
, the
default behavior is to create an auto-extending data file named
ibtmp1
in the data directory that is
slightly larger than 12MB. The shared temporary tablespace is
removed and recreated each time the server is started.
In previous releases, temporary tables are created in individual
file-per-table tablespaces in the temporary file directory, or
in the InnoDB
system tablespace in the data
directory if
innodb_file_per_table
is
disabled. Compressed temporary tables are still created in
file-per-table tablespaces in the temporary file directory.
A shared temporary tablespace removes performance costs
associated with creating and removing a file-per-table
tablespace for each temporary table. A dedicated temporary
tablespace also means that it is no longer necessary to save
temporary table metadata to the InnoDB
system
tables.
(WL #6560)
InnoDB:
Prior to this release, InnoDB
stored spatial
data types as binary BLOB
data,
mapped to the internal DATA_BLOB
data type.
BLOB
remains the underlying data type but
spatial data types are now mapped to a new internal data type,
DATA_GEOMETRY
. With
BLOB
as the underlying data type,
a prefix index can still be used on all
GEOMETRY
data type columns.
InnoDB:
DDL performance for user and system-created
InnoDB
temporary tables was optimized by
avoiding operations that are only necessary for regular
InnoDB
tables. Those operations include redo
logging (required for recovery), writing of table definition
metadata to InnoDB
system tables, and insert
buffering. DDL operations that benefit from the optimization
include CREATE TABLE
, DROP
TABLE
, TRUNCATE TABLE
, and
ALTER TABLE
, including ALTER TABLE
... IMPORT TABLESPACE
and ALTER TABLE ...
DISCARD TABLESPACE
.
As a result of the optimization, InnoDB
temporary table metadata no longer appears in
INFORMATION_SCHEMA
views that previously
included that data. Instead, a new
INFORMATION_SCHEMA
table,
INNODB_TEMP_TABLE_INFO
, provides a
snapshot of active user-created temporary tables within an
InnoDB
instance. Additionally, the number of
InnoDB
temporary tables that can exist at one
time is now limited by the amount of memory available (for
temporary table definitions) on the system that runs the MySQL
server process, as temporary table definitions can no longer be
placed on the LRU list and swapped out.
(WL #6469)
InnoDB:
DDL performance for InnoDB
temporary tables
is improved through optimization of CREATE
TABLE
, DROP TABLE
,
TRUNCATE TABLE
, and
ALTER TABLE
statements.
Optimizations were achieved by limiting actions performed by DDL
statements to only those necessary for temporary tables.
InnoDB:
VARCHAR
column size can now be
increased using an in-place ALTER
TABLE
, as in this example:
ALTER TABLE t1 ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(255);
This is true as long as the number of length bytes required by a
VARCHAR
column remains the same.
For VARCHAR
columns of 0 to 255
bytes in size, one length byte is required to encode the value.
For VARCHAR
columns of 256 bytes
in size or more, two length bytes are required. As a result,
in-place ALTER TABLE
only
supports increasing VARCHAR
column size from 0 to 255 bytes, or from 256 bytes to a greater
size. In-place ALTER TABLE
does
not support increasing the size of a
VARCHAR
column from less than 256
bytes to a size equal to or greater than 256 bytes. In this
case, the number of required length bytes changes from 1 to 2,
which is only supported by a table copy
(ALGORITHM=COPY
).
Decreasing VARCHAR
size using
in-place ALTER TABLE
is not
supported. Decreasing VARCHAR
size requires a table copy (ALGORITHM=COPY
).
For more information, see Online DDL Operations.
InnoDB:
Online index renaming is supported by ALTER
TABLE
, which now includes a RENAME
INDEX
clause, as shown in the following example:
“ALTER TABLE t RENAME INDEX i1 TO
i2
”, where i1
is the current
name of the index and i2
is the new name.
The result of “ALTER TABLE t RENAME INDEX i1 TO
i2
” would be a table with contents and
structure that is identical to the old version of
“t1” except for the index name, which is now
“i2” instead of “i1”.
Partitioning:
HANDLER
statements are now
supported with partitioned tables.
(WL #6497)
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)
Replication:
The functions GTID_SUBTRACT()
and
GTID_SUBSET()
were formerly
available in libmysqld
only when it was built
with replication support. Now these functions are always
available when using this library, regardless of how it was
built.
Replication:
Added the --rewrite-db
option for mysqlbinlog, which allows
mysqlbinlog to rewrite the names of databases
when playing back binary logs written using the row-based
logging format. Multiple rewrite rules can be created by
specifying the option multiple times.
(WL #6404)
MySQL no longer uses the default OpenSSL compression. (Bug #16235681)
There is now a distinct error code
(ER_MUST_CHANGE_PASSWORD_LOGIN
)
for the error sent by the server to a client authenticating with
an expired password.
(Bug #16102943)
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)
mysqldump now supports an
--ignore-error
option. The
option value is a comma-separated list of error numbers
specifying the errors to ignore during
mysqldump execution. If the
--force
option is also given
to ignore all errors, --force
takes precedence.
(Bug #15855723)
mysql_config_editor now supports
--port
and --socket
options
for specifying TCP/IP port number and Unix socket file name.
(Bug #15851247)
mysqlcheck has a new
--skip-database
option. The
option value is the name of a database (case sensitive) for
which checks should be skipped.
mysql_upgrade adds this option to
mysqlcheck commands that it generates to
upgrade the system tables in the mysql
database before tables in other databases: It upgrades the
mysql
database, then all databases except the
mysql
database. This avoids problems that can
occur if user tables are upgraded before the system tables.
(Bug #14697538, Bug #68163, Bug #16216384)
The validate_password_policy_number
system
variable was renamed to
validate_password_policy
.
(Bug #14588121)
Previously, on Linux the server failed to perform stack
backtrace attempts for versions of glibc
older than the current minimum supported version (2.3). Now on
such attempts the server displays a message that the
glibc
version is too old to support
backtracing.
(Bug #14475946)
In JSON-format EXPLAIN
output,
the attached_condition
information for
subqueries now includes select#
to indicate
the relative order of subquery execution.
(Bug #13897507)
If a user attempted to access a nonexistent column for which the user had no access, the server returned an error indicating that the column did not exist. Now the server returns an error indicating that the user does not have privileges for the column, which provides no information about column existence. (Bug #19947, Bug #11745788)
The MySQL test suite mysql-test-run.sh
program now starts the server with InnoDB
rather than MyISAM
as the default storage
engine. To maintain compatibility of test results with existing
result files, test cases were modified to add a line that
includes the force_default_myisam.inc
file
as necessary. In a future release, for those test cases not
specifically requiring MyISAM
, that line will
be removed (so they run with InnoDB
) and test
results will be updated.
(WL #6731)
ALTER TABLE
now supports a
RENAME INDEX
clause that renames an index.
The change is made in place without a table-copy operation.
(WL #6555)
The mysql client now has a
--syslog
option that causes
interactive statements to be sent to the system
syslog
facility. Logging is suppressed for
statements that match the default “ignore” pattern
list ("*IDENTIFIED*:*PASSWORD*"
), as well as
statements that match any patterns specified using the
--histignore
option. For more
information, see mysql Client Logging.
(WL #6788)
Incompatible Change; Partitioning:
Changes in the KEY
partitioning hashing
functions used with numeric, date and time,
ENUM
, and
SET
columns in MySQL 5.5 makes
tables using partitioning or subpartitioning by
KEY
on any of the affected column types and
created on a MySQL 5.5 or later server incompatible with a MySQL
5.1 server. This is because the partition IDs as calculated by a
MySQL 5.5 or later server almost certainly differ from those
calculated by a MySQL 5.1 server for the same table definition
and data as a result of the changes in these functions.
The principal changes in the KEY
partitioning
implementation in MySQL 5.5 resulting in this issue were as
follows: 1. The hash function used for numeric and date and time
columns changed from binary to character-based. 2. The base used
for hashing of ENUM
and
SET
columns changed from latin1
ci
characters to binary.
The fix involves adding the capability in MySQL 5.5 and later to
choose which type of hashing to use for KEY
partitioning, which is implemented with a new
ALGORITHM
extension to the PARTITION
BY KEY
option for CREATE
TABLE
and ALTER TABLE
.
Specifying PARTITION BY KEY ALGORITHM=1
([
causes the
server to use the hashing functions as implemented in MySQL 5.1;
using columns
])ALGORITHM=2
causes the server to use
the hashing functions from MySQL 5.5 and later.
ALGORITHM=2
is the default. Using the
appropriate value for ALGORITHM
, you can
perform any of the following tasks:
Create KEY
partitioned tables in MySQL
5.5 and later that are compatible with MySQL 5.1, using
CREATE TABLE ... PARTITION BY KEY ALGORITHM=1
(...)
.
Downgrade KEY
partitioned tables that
were created in MySQL 5.5 or later to become compatible with
MySQL 5.1, using ALTER TABLE ... PARTITION BY KEY
ALGORITHM=1 (...)
.
Upgrade KEY
partitioned tables originally
created in MySQL 5.1 to use hashing as in MySQL 5.5 and
later, using ALTER TABLE ... PARTITION BY KEY
ALGORITHM=2 (...)
.
Important: After such tables are
upgraded, they cannot be used any longer with MySQL 5.1
unless they are first downgraded again using ALTER
TABLE ... PARTITION BY KEY ALGORITHM=1 (...)
on a
MySQL server supporting this option.
This syntax is not backward compatible, and causes errors in
older versions of the MySQL server. When generating
CREATE TABLE ...
PARTITION BY KEY
statements,
mysqldump brackets any occurrence of
ALGORITHM=1
or ALGORITHM=2
in conditional comments such that it is ignored by a MySQL
server whose version is not at least 5.5.31. An additional
consideration for upgrades is that MySQL 5.6 servers prior to
MySQL 5.6.11 do not ignore the ALGORITHM
option in such statements when generated by a MySQL 5.5 server,
due to the that the conditional comments refer to version
5.5.31; in this case, you must edit the dump manually and remove
or comment out the option wherever it occurs before attempting
to load it into a MySQL 5.6.10 or earlier MySQL 5.6 server. This
is not an issue for dumps generated by MySQL 5.6.11 or later
version of mysqldump, where the version used
in such comments is 5.6.11. For more information, see
ALTER TABLE Partition Operations.
As part of this fix, a spurious assertion by
InnoDB
that a deleted row had
previously been read, causing the server to assert on delete of
a row that the row was in the wrong partition, was also removed.
(Bug #14521864, Bug #66462, Bug #16093958, Bug #16274455)
References: See also: Bug #11759782.
Incompatible Change: For debug builds, creating an InnoDB table in strict SQL mode that violated the maximum key length limit caused the server to exit.
A behavior change in consequence of this bug fix: In strict SQL mode, a key length limit violation now results in a error (and the table is not created), rather than a warning and truncation of the key to the maximum key length. This applies to all storage engines. (Bug #16035659)
Important Change; Plugin API; Replication:
Because the behavior of the fulltext plugin may vary between
MySQL servers, it is not possible to guarantee that statements
using this plugin produce the same results on masters and
slaves. For this reason, statements depending on the fulltext
plugin are now marked as unsafe for statement-based logging.
This means that such statements are logged using row format when
binlog_format=MIXED
, and cause
a warning to be generated when
binlog_format=STATEMENT
.
(Bug #11756280, Bug #48183)
Important Change; Replication
This fix was reverted in MySQL 5.7.2. See Section 44, “Changes in MySQL 5.7.2 (2013-09-21, Milestone 12)”.
Executing a statement that performs an implicit commit but whose
changes are not logged when
gtid_next
is set to any value
other than AUTOMATIC
is not permitted. Now in
such cases, the statement fails with an error. This includes the
statements in the following list:
(Bug #16062608)
References: See also: Bug #16484323.
Important Change; Replication:
The version number reported by mysqlbinlog
--version
has been increased
to 3.4.
(Bug #15894381, Bug #67643)
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)
Important Note; Replication: Using row-based logging to replicate from a table to a same-named view led to a failure on the slave. Now, when using row-based logging, the target object type is checked prior to performing any DML, and an error is given if the target on the slave is not actually a table.
It remains possible to replicate from a table to a same-named view using statement-based logging.
(Bug #11752707, Bug #43975)
Performance; InnoDB:
The DROP TABLE
statement for a
table using compression
could be slower than necessary, causing a stall for several
seconds. MySQL was unnecessarily decompressing
pages in the
buffer pool related to
the table as part of the DROP
operation.
(Bug #16067973)
NDB Cluster:
The setting for the
DefaultOperationRedoProblemAction
API node configuration parameter was ignored, and the default
value used instead.
(Bug #15855588)
NDB Cluster: Job buffers act as the internal queues for work requests (signals) between block threads in ndbmtd and could be exhausted if too many signals are sent to a block thread.
Performing pushed joins in the DBSPJ
kernel
block can execute multiple branches of the query tree in
parallel, which means that the number of signals being sent can
increase as more branches are executed. If
DBSPJ
execution cannot be completed before
the job buffers are filled, the data node can fail.
This problem could be identified by multiple instances of the message sleeploop 10!! in the cluster out log, possibly followed by job buffer full. If the job buffers overflowed more gradually, there could also be failures due to error 1205 (Lock wait timeout exceeded), shutdowns initiated by the watchdog timer, or other timeout related errors. These were due to the slowdown caused by the 'sleeploop'.
Normally up to a 1:4 fanout ratio between consumed and produced signals is permitted. However, since there can be a potentially unlimited number of rows returned from the scan (and multiple scans of this type executing in parallel), any ratio greater 1:1 in such cases makes it possible to overflow the job buffers.
The fix for this issue defers any lookup child which otherwise would have been executed in parallel with another is deferred, to resume when its parallel child completes one of its own requests. This restricts the fanout ratio for bushy scan-lookup joins to 1:1. (Bug #14709490)
References: See also: Bug #14648712.
NDB Cluster: The recently added LCP fragment scan watchdog occasionally reported problems with LCP fragment scans having very high table id, fragment id, and row count values.
This was due to the watchdog not accounting for the time spent draining the backup buffer used to buffer rows before writing to the fragment checkpoint file.
Now, in the final stage of an LCP fragment scan, the watchdog switches from monitoring rows scanned to monitoring the buffer size in bytes. The buffer size should decrease as data is written to the file, after which the file should be promptly closed. (Bug #14680057)
InnoDB:
When parsing a delimited search string such as
“abc-def” in a full-text search,
InnoDB
now uses the same word delimiters as
MyISAM
.
(Bug #16419661)
InnoDB:
Naming inconsistencies were addressed for InnoDB
PERFORMANCE_SCHEMA
key declarations.
(Bug #16414044)
InnoDB:
Status values in the
innodb_ft_config
table would not
update. The innodb_ft_config
is
intended for internal configuration and should not be used for
statistical information purposes. To avoid confusion, column
values that are intended for internal use have been removed from
the innodb_ft_config
table. This
fix also removes the
innodb_ft_config
table and other
internal full text search-related tables that were
unintentionally exposed.
(Bug #16409494, Bug #68502)
InnoDB: This fix disables a condition for extra splitting of clustered index leaf pages, on compressed tables. Extra page splitting was only done to reserve space for future updates, so that future page splits could be avoided. (Bug #16401801)
InnoDB:
For InnoDB
tables, if a PRIMARY
KEY
on a VARCHAR
column
(or prefix) was empty, index page compression could fail.
(Bug #16400920)
InnoDB:
The InnoDB
page-splitting algorithm could
recurse excessively.
(Bug #16345265)
InnoDB:
Improper testing of compatibility between the referencing and
referenced during
ALTER TABLE ... ADD
FOREIGN
key could cause a server exit.
(Bug #16330036)
InnoDB: Importing a tablespace with the configuration file present would not import the data file. This problem would occur when all pages are not flushed from the buffer pool after a table is altered using the copy and rename approach. This fix ensures that all pages are flushed from the buffer pool when a table is altered using the copy and rename approach. (Bug #16318052)
InnoDB: Rollback did not include changes made to temporary tables by read-only transactions. (Bug #16310467)
InnoDB:
When using ALTER TABLE
to set an
AUTO_INCREMENT
column value to a
user-specified value, InnoDB would set the
AUTO_INCREMENT
value to the user-specified
value even when the AUTO_INCREMENT
value is
greater than the user-specified value. This fix ensures that the
AUTO_INCREMENT
value is set to the maximum of
the user-specified value and MAX(auto_increment_column)+1, which
is the expected behaviour.
(Bug #16310273)
InnoDB:
For debug builds, InnoDB
status exporting was
subject to a race condition that could cause a server exit.
(Bug #16292043)
InnoDB:
With innodb_api_enable_mdl=OFF
,
an ALTER TABLE
operation on an
InnoDB
table that required a table copy could
cause a server exit.
(Bug #16287411)
InnoDB:
An assertion failure would occur in heap->magic_n ==
MEM_BLOCK_MAGIC_N
due to a race condition that
appeared when
row_merge_read_clustered_index()
returned an
error.
(Bug #16275237)
InnoDB:
InnoDB now aborts execution on Windows by calling the
abort()
function directly, as it does on
other platforms.
(Bug #16263506)
InnoDB: This fix removes an unnecessary debug assertion related to page_hash locks which only affects debug builds. The debug assertion is no longer valid and should have been removed when hash_lock array was introduced in MySQL 5.6. (Bug #16263167)
InnoDB:
Without warning, InnoDB would silently set
innodb-buffer-pool-instances
to 1 if the
buffer pool size is less than 1GB. For example, if
innodb-buffer-pool-size
is set to 200M and
innodb-buffer-pool-instances
is set to 4,
InnoDB would silently set
innodb-buffer-pool-instances
to 1. This fix
implements a warning message and new logic for
innodb-buffer-pool-size
and
innodb-buffer-pool-instances
.
(Bug #16249500, Bug #61239)
InnoDB:
The lock_validate
function, which is only
present in debug builds, acquired and released mutexes to avoid
hogging them. This behavior introduced a window wherein changes
to the hash table could occur while code traversed the same set
of data. This fix updates lock_validate
logic
to collect all records for which locks must be validated,
releases mutexes, and runs a loop to validate record locks.
(Bug #16235056)
InnoDB:
ALTER TABLE
functions would
perform a check to see if InnoDB is in read-only mode
(srv_read_only_mode=true
). If InnoDB was in
read-only mode, the check would return a successful status and
do nothing else. This fix replaces
srv_read_only_mode
check conditions with
debug assertions.
(Bug #16227539)
InnoDB:
When the InnoDB buffer pool is almost filled with 4KB compressed
pages, inserting into 16KB compact tables would cause 8KB
pages_free
to increase, which could
potentially slow or stall inserts.
(Bug #16223169)
InnoDB:
This fix updates InnoDB code in ha_innodb.cc
and handler0alter.cc
to use
TABLE::key_info
instead of both
TABLE::key_info
and
TABLE_SHARE::key_info
.
(Bug #16215361)
InnoDB: When InnoDB locking code was revised, a call to register lock waits was inadvertently removed. This fix adds the call back to the InnoDB locking code. (Bug #16208201)
InnoDB:
A direct call to the
trx_start_if_not_started_xa_low()
function
would cause a debug assertion.
(Bug #16178995)
InnoDB:
In the case of LOCK WAIT for an insert in a foreign key table,
InnoDB
could report a false
dictionary-changed error and cause the insert to fail rather
than being retried.
(Bug #16174255)
InnoDB:
An in-place ALTER TABLE
on an
InnoDB
table could fail to delete the
statistics for the old primary key from the
mysql.innodb_index_stats
table.
(Bug #16170451)
InnoDB: In some cases, deadlock detection did not work, resulting in sessions hanging waiting for a lock-wait timeout. (Bug #16169638)
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:
LOCK_TIME
would not be logged correctly in
the slow query log. LOCK_TIME
did not account
for InnoDB row lock wait time.
(Bug #16097753)
InnoDB:
Arithmetic underflow during page compression for
CREATE TABLE
on an
InnoDB
table could cause a server exit.
(Bug #16089381)
InnoDB:
For debug builds, online ALTER
TABLE
operations for InnoDB
tables
could cause a server exit during table rebuilding.
(Bug #16063835)
InnoDB:
In some cases, the InnoDB
purge coordinator
did not use all available purge threads, resulting in suboptimal
purge activity.
(Bug #16037372)
InnoDB:
ALTER TABLE
for
InnoDB
tables was not fully atomic.
(Bug #15989081)
InnoDB:
This fix replaces most uses of
UT_SORT_FUNCTION_BODY
, an InnoDB recursive
merge sort, with the std::sort()
function
from the C++ Standard Template Library (STL). The
std::sort()
function requires less memory and
is faster due to in-line execution.
(Bug #15920744)
InnoDB:
This fix addresses unnecessary buffer pool lookups that would
occur while freeing blob pages, and implements a debug status
instrument, innodb_ahi_drop_lookups
, for
testing purposes.
(Bug #15866009)
InnoDB:
This fix implements a 256-byte boundary for extending a
VARCHAR
column instead of 256-character
boundary. This change allows for in-place extension of a
VARCHAR
column through an update of the data
dictionary.
(Bug #15863023)
InnoDB:
Creating numerous tables, each with a full-text search index,
could result in excessive memory consumption. This bug fix adds
a new configuration parameter,
innodb_ft_total_cache_size
,
which defines a global memory limit for full-text search
indexes. If the global limit is reached by an index operation, a
force sync is triggered.
(Bug #14834698, Bug #16817453)
InnoDB:
This fix modifies InnoDB
code to ensure that
unused thread handles are closed when the thread exits, instead
of leaving thread handles open until shutdown of
mysqld on Windows.
(Bug #14762796)
InnoDB:
This fix removes unnecessary overhead by removing table locking
and disabling read view creation and MVCC when InnoDB is started
in read-only mode (--innodb-read-only=true
).
(Bug #14729365)
InnoDB: A regression introduced by the fix for Bug#14100254 would result in a “!BPAGE->FILE_PAGE_WAS_FREED” assertion. (Bug #14676249)
InnoDB: Full-text search (FTS) index savepoint information would not be set resulting in a severe error when attempting to rollback to the savepoint. (Bug #14639605, Bug #17456092)
InnoDB:
The innodb_sync_array_size
variable was incorrectly allowed to be configured at runtime. As
documented,
innodb_sync_array_size
must be
configured when the MySQL instance is starting up, and cannot be
changed afterward. This fix changes
innodb_sync_array_size
to a
non-dynamic variable, as intended.
(Bug #14629979)
InnoDB:
An error at the filesystem level, such as too many open files,
could cause an unhandled error during an
ALTER TABLE
operation. The error
could be accompanied by Valgrind warnings, and by this assertion
message:
Assertion `! is_set()' failed. mysqld got signal 6 ;
(Bug #14628410, Bug #16000909)
InnoDB:
The server could exit during an attempt by
InnoDB
to reorganize or compress a compressed
secondary index page.
(Bug #14606334)
InnoDB:
A DML operation performed while a RENAME
TABLE
operation waits for pending I/O operations on
the tablespace to complete would result in a deadlock.
(Bug #14556349)
InnoDB: Attempting to unninstall the InnoDB memcached plugin while the plugin is still installing caused the Mysql server to terminate. While the plugin deamon thread was still initializing, plugin variables were not yet set and the uninstall process could not cleanup resources. This fix adds a variable to indicate initialization status. If initialization is incomplete, the uninstall process will wait. (Bug #14279541)
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:
When printing out long semaphore wait diagnostics,
sync_array_cell_print()
ran into a
segmentation violation (SEGV) caused by a race condition. This
fix addresses the race condition by allowing the cell to be
freed while it is being printed.
(Bug #13997024)
InnoDB:
Attempting to replace the default InnoDB
full-text search (FTS) stopword list by creating an
InnoDB
table with the same structure as
INFORMATION_SCHEMA.INNODB_FT_DEFAULT_STOPWORD
would result in an error. SHOW CREATE
TABLE
revealed that the new InnoDB
table was created with CHARSET=utf8
. The
InnoDB
FTS stopword table validity check only
supported latin1. This fix extends the validity check for all
supported character sets.
(Bug #68450, Bug #16373868)
InnoDB:
This fix removes left-over prototype code for
srv_parse_log_group_home_dirs
, and related
header comments.
(Bug #68133, Bug #16198764)
InnoDB: Killing a query caused an InnoDB assertion failure when the same table (cursor) instance was used again. This is the result of a regression error introduced by the fix for Bug#14704286. The fix introduced a check to handle kill signals for long running queries but the cursor was not restored to the proper state. (Bug #68051, Bug #16088883)
InnoDB: On startup, InnoDB reported a message on 64-bit Linux and 64-bit Windows systems stating that the CPU does not support crc32 instructions. On Windows, InnoDB does not use crc32 instructions even if supported by the CPU. This fix revises the wording of the message and implements a check for availability of crc32 instructions. (Bug #68035, Bug #16075806)
InnoDB:
The length of internally generated foreign key names was not
checked. If internally generated foreign key names were over the
64 character limit, this resulted in invalid DDL from
SHOW CREATE TABLE
. This fix checks the length
of internally generated foreign key names and reports an error
message if the limit is exceeded.
(Bug #44541, Bug #11753153)
Partitioning:
A query on a table partitioned by range and using
TO_DAYS()
as a partitioing
function always included the first partition of the table when
pruning. This happened regardless of the range employed in the
BETWEEN
clause of such a query.
(Bug #15843818, Bug #49754)
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.
Partitioning:
Execution of
ALTER
TABLE ... DROP PARTITION
against a view caused the
server to crash, rather than fail with an error as expected.
(Bug #14653504)
Partitioning:
A query result was not sorted if both
DISTINCT
and ORDER BY
were
used and the underlying table was partitioned.
(Bug #14058167)
Partitioning:
Inserting any number of rows into an
ARCHIVE
table that used more than
1000 partitions and then attempting to drop the table caused the
MySQL Server to fail.
(Bug #13819630, Bug #64580)
Replication; Linux; Microsoft Windows:
Replication failed between a Linux master using
lower_case_table_names
set to 0
and a Windows slave having
lower_case_table_names
set to 2, after a
replicated table was opened on the slave; in addition,
FLUSH TABLES
was required
afterwards to see which updates had actually been applied on the
slave. This was because
lower_case_table_names
was checked only to
see whether it was equal to 1 prior to forcing a conversion of
replicated database object names to lower case for checking the
table cache. Now in such cases,
lower_case_table_names
is
checked to see whether it is set to a nonzero value.
(Bug #16061982)
Replication; Microsoft Windows:
When the binlog.index
file ended with
\r\n
(CR+LF), MySQL wrongly included the
\r
character in the name of the file it tried
to open, causing replication to fail. This could cause problems
with restarting the server after editing this file on a Windows
system.
(Bug #11757413, Bug #49455)
Replication: When using GTIDs and binary log auto-positioning, the master had to scan all binary logs whenever the slave reconnected (due to reasons such as I/O thread failure or a change of master) before it could send any events to slave. Now, the master starts from the oldest binary log that contains any GTID not found on the slave. (Bug #16340322, Bug #68386)
Replication: When the server version of the master was greater than or equal to 10, replication to a slave having a lower server version failed. (Bug #16237051, Bug #68187)
Replication:
When replicating to a MySQL 5.6 master to an older slave, Error
1193
(ER_UNKNOWN_SYSTEM_VARIABLE
) was
logged with a message such as Unknown system variable
'SERVER_UUID' on master, maybe it is a *VERY OLD
MASTER*. This message has been improved to include
more information, similar to this one: Unknown system
variable 'SERVER_UUID' on master. A probable cause is that the
variable is not supported on the master (version: 5.5.31), even
though it is on the slave (version: 5.6.11).
(Bug #16216404, Bug #68164)
Replication:
The print format specifier for the server_id
was incorrectly defined as a signed 32-bit integer with a range
of -2144783647 to 2144783648. This fix changes the
server_id
integer type to an unsigned 32-bit
integer type, with a range of 0 to 4294967295, which is the
documented range for the --server-id
option.
(Bug #16210894)
Replication:
When MTS is on and transactions are being applied, the slave
coordinator would hang when encountering a checksum error on a
transaction event. This was due to a deadlock situation in which
the coordinator assumed a normal stop while a worker waited for
the coordinator to dispatch more events. For debug builds, the
problem appeared as an assertion failure, which was due to the
coordinator not setting thd->is_error()
when encountering an error.
(Bug #16210351)
Replication:
A zero-length name for a user variable (such as
@``
) was incorrectly considered to be a sign
of data or network corruption when reading from the binary log.
(Bug #16200555, Bug #68135)
Replication:
Running SHOW RELAYLOG EVENTS
at a slave where
no relay log file is present returned the following incorrect
error message: "Error when executing command SHOW
BINLOG EVENTS: Could not find target log.
" The error
message text has been changed to: "Error when executing
command SHOW RELAYLOG EVENTS: Could not find target
log.
"
(Bug #16191895)
Replication:
mysqlbinlog can connect to a remote server
and read its binary logs. In MySQL 5.6 and later, this tool can
also wait for the server to generate and send additional events,
in practice behaving like a slave connecting to a master. In
cases where the server sent a heartbeat,
mysqlbinlog was unable to handle it properly.
As a consequence, mysqlbinlog failed at this
point, without reading any more events from the server. To fix
this problem, mysqlbinlog now ignores any
binary log events of type HEARTBEAT_LOG_EVENT
that it receives.
(Bug #16104206)
Replication:
STOP SLAVE
could cause a deadlock
when issued concurrently with a statement such as
SHOW STATUS
that retrieved the
values for one or more of the status variables
Slave_retried_transactions
,
Slave_heartbeat_period
,
Slave_received_heartbeats
,
Slave_last_heartbeat
, or
Slave_running
.
(Bug #16088188, Bug #67545)
References: See also: Bug #16088114.
Replication:
Backtick (`
) characters were not always
handled correctly in internally generated SQL statements, which
could sometimes lead to errors on the slave.
(Bug #16084594, Bug #68045)
References: This issue is a regression of: Bug #14548159, Bug #66550.
Replication:
In order to provision or to restore a server using GTIDs, it is
possible to set gtid_purged
to
a given GTID set listing the transactions that were imported.
This operation requires that the global
gtid_executed
and
gtid_purged
server system
variables are empty. (This is done in order to avoid the
possibility of overriding server-generated GTIDs.)
The error message GTID_PURGED can only be set when GTID_EXECUTED is empty that was raised when this requirement was not met could be confusing or misleading because it did not specify the scope of the affected variables. To prevent this from happening, error messages that refer to variables relating to GTIDs now specify the scope of any such variables when they do so. (Bug #16084426, Bug #68038)
Replication:
The session-level value for
gtid_next
was incorrectly reset
on the slave for all rollbacks, which meant that GTIDs could be
lost for multi-statement transactions, causing the slave to stop
with an
ER_GTID_NEXT_TYPE_UNDEFINED_GROUP
error. Now this is done only when a complete transaction is
being rolled back, or when
autocommit
is enabled.
(Bug #16084206)
Replication: Dropping a table that includes non-regular ASCII characters in the table name caused a replication failure. The parser converted the table name into standard charset characters and stored the table name in the table_name variable. When the drop table query was regenerated using the table_name variable, the table name was not converted back to the original charset.
Additionally, table and database names with 64 characters caused an assert failure. The assert required the table or database name to be less than 128 characters. Latin characters require two-bytes each, which requires an assert condition of less than or equal to 128 bits.
The fix includes a new function to convert tables names back to the original charset, and a correction to the assert condition allowing table and database names be less than or equal to 128 bits. (Bug #16066637)
Replication:
Using the --replicate-*
options (see
Replica Server Options and Variables) could in some
cases lead to a memory leak on the slave.
(Bug #16056813, Bug #67983)
Replication: In some cases, when the slave could not recognize the server version of the master, this could cause the slave to fail. (Bug #16056365)
Replication:
In certain cases, the dump thread could send a heartbeat out of
synchronisation with format description events. One of the
effects of this issue what that, after provisioning a new server
from a backup data directory and setting
--gtid-mode=ON
and enabling
autopositioning (see CHANGE MASTER TO Statement),
replication failed to start, with the error Read
invalid event from master.... The same problem could
also cause GTID-based replication to fail due to skipped events
following a unplanned shutdown of the master.
(Bug #16051857)
Replication:
Replication failed when a replicated LOAD
DATA
statement inserted rows into a view.
(Bug #15993712, Bug #67878)
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 read a table map event from the binary log, it assumed that the metadata size was always less than twice the column count of the table in use, which failed when the event contained the wrong value for this field. (Bug #15830022)
Replication: When reading row log events from the binary log, the slave assumed that these events were always valid; because of this, an event having an invalid binary log offset could cause the slave to crash. Now in such cases, the slave fails gracefully, and an error is reported, if any of the fields in a given row event are invalid. (Bug #15829568)
Replication:
Table IDs used in replication were defined as type
ulong
on the master and
uint
on the slave. In addition, the maximum
value for table IDs in binary log events is 6 bytes
(281474976710655). This combination of factors led to the
following issues:
Data could be lost on the slave when a table was assigned an
ID greater than uint
.
Table IDs greater than 281474976710655 were written to the binary log as 281474976710655.
This led to a stopped slave when the slave encountered two tables having the same table ID.
To fix these problems, IDs are now defined by both master and
slave as type ulonglong
but constrained to a
range of 0 to 281474976710655, restarting from 0 when it exceeds
this value.
(Bug #14801955, Bug #67352)
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: Internal objects used for relay log information were only partially deleted before freeing their memory. (Bug #14677824)
Replication: When the server starts, it checks whether semisynchronous replication has been enabled without a lock, and, if so, it takes the lock, then tests again. Disabling semisynchronous replication following the first of the these tests, but prior to the second one, could lead to a crash of the server. (Bug #14511533, Bug #66411)
Replication: It was possible in certain cases—immediately after detecting an EOF in the dump thread read event loop, and before deciding whether to change to a new binary log file—for new events to be written to the binary log before this decision was made. If log rotation occurred at this time, any events that occurred following EOF detection were dropped, resulting in loss of data. Now in such cases, steps are taken to make sure that all events are processed before allowing the log rotation to take place. (Bug #13545447, Bug #67929)
References: See also: Bug #16016886.
Replication:
It was possible for the
MASTER_POS_WAIT()
function to
return prematurely following a CHANGE
MASTER TO
statement that updated the
RELAY_LOG_POS
or
RELAY_LOG_NAME
. This could happen because
CHANGE MASTER TO
did not update the master
log position in such cases, causing
MASTER_POS_WAIT()
to read an invalid log
position and to return immediately.
To fix this problem, the master log position is flagged as
invalid until the position is set to a valid value when the SQL
thread reads the first event, after which it is flagged as
valid. Functions such as MASTER_POS_WAIT()
now defer any comparison with the master log position until a
valid value can be obtained (that is, after the first event
following the CHANGE MASTER TO
statement has
been applied).
(Bug #11766010, Bug #59037)
Replication: If the disk becomes full while writing to the binary log, the server hangs until space is freed up manually. It was possible after this was done for the MySQL server to fail, due to an internal status value being set when not needed. Now in such cases, rather than trying to set this status, a warning is written in the error log instead. (Bug #11753923, Bug #45449)
Replication: The binary log and relay log files used the name of the PID file instead of the host name as the basename. (Bug #11753843, Bug #45359)
Microsoft Windows:
A server started with
--shared-memory
to support
shared-memory connections could crash when receiving requests
from multiple threads.
(Bug #13934876)
Microsoft Windows:
On Windows, the log_error
system variable did not accurately reflect the error log file
name in some cases. For example, if the server was started
without --console
or
--log-error
, the default is to
log to
in
the data directory, but host_name
.errlog_error
remained
blank.
Now log_error
should be nonblank and reflect
the log file name in all cases, on all platforms. The value is
stderr
if the server does not write error
messages to a file and sends them to the console (standard error
output) instead. In particular, on Windows,
--console
overrides use of an error log and
sends error messages to the console, so
log_error
will be set to
stderr
.
(Bug #8307, Bug #11745049)
Solaris: mysql_install_db did not work in Solaris 10 sparse root zones. (Bug #68117, Bug #16197860)
RPM packages were missing the
innodb_engine.so
and
libmemcached.so
plugins.
(Bug #17001088)
Windows MSI installers for MySQL 5.7 had a 5.6 upgrade code, not a 5.7 upgrade code. (Bug #16445344)
SHOW ENGINE PERFORMANCE_SCHEMA STATUS
could
report incorrect memory-allocation values when the correct
values exceeded 4GB.
(Bug #16414644)
The server could exit if a prepared statement attempted to create a table using the name of an existing view while an SQL handler was opened. (Bug #16385711)
Performance Schema statement tokenization overhead was reduced. (Bug #16382260)
A long database name in a GRANT
statement could cause the server to exit.
(Bug #16372927)
Some aggregate queries attempted to allocate excessive memory. (Bug #16343992)
For debug builds, an assertion could be raised if a statement
failed with autocommit enabled just before an
XA START
statement
was issued.
(Bug #16341673)
Very small join_buffer_size
values could cause an assertion to be raised.
(Bug #16328373)
The BUILD-CMAKE
file in MySQL distributions
was updated with the correct URL for CMake
information.
(Bug #16328024)
The optimizer's attempt to remove redundant subquery clauses
raised an assertion when executing a prepared statement with a
subquery in the ON
clause of a join in a
subquery.
(Bug #16318585)
References: This issue is a regression of: Bug #15875919.
Incorrect results were returned if a query contained a subquery
in an IN
clause which contained an
XOR
operation in the
WHERE
clause.
(Bug #16311231)
A Valgrind failure could occur if a CREATE
USER
statement was logged to the general query log and
the old_passwords
system
variable was set to 2.
(Bug #16300620)
For debug builds, checking of password constraints could raise an assertion for statements that updated passwords. (Bug #16289303)
Conversion of numeric values to
BIT
could yield unexpected
results.
(Bug #16271540)
Fixed warnings when compiling with XCode 4.6. Fixed warnings
when compiling when the _XOPEN_SOURCE
or
isoctal
macro was already defined in the
environment.
(Bug #16265300, Bug #60911, Bug #12407384)
In the range optimizer, an index merge failure could cause a server exit. (Bug #16241773)
For upgrade operations, RPM packages produced unnecessary errors
about being unable to access .err
files.
(Bug #16235828)
Queries using range predicates that were evaluated using the LooseScan semijoin strategy could return duplicate rows. (Bug #16221623)
References: This issue is a regression of: Bug #14728469.
Certain legal HAVING
clauses were rejected as
invalid.
(Bug #16221433)
yaSSL did not perform proper padding checks, but instead examined only the last byte of cleartext and used it to determine how many bytes to remove. (Bug #16218104)
The Performance Schema could return incorrect values for the
PROCESSLIST_INFO
column of the
threads
table.
(Bug #16215165)
mysql_config --libs displayed incorrect output. (Bug #16200717)
Invocation of the range optimizer for a NULL
select caused the server to exit.
(Bug #16192219)
For debug builds, the server could exit due to incorrect
calculation of applicable indexes for a join that involved
const
tables.
(Bug #16165832)
For a CREATE TABLE (...
statement for which
the col_name
TIMESTAMP DEFAULT
CURRENT_TIMESTAMP ...) ... SELECTSELECT
did not provide a value for the
TIMESTAMP
column, that column was set to
'0000-00-00 00:00:00', not the current timestamp.
(Bug #16163936)
Using GROUP BY WITH ROLLUP
in a prepared
statement could cause the server to exit.
(Bug #16163596)
With the thread pool plugin enabled, large numbers of connections could lead to a Valgrind panic or failure of clients to be able to connect. (Bug #16088658, Bug #16196591)
Performance Schema instrumentation was missing for slave worker threads. (Bug #16083949)
The server executed
EXPLAIN
FORMAT=JSON
for some malformed queries improperly.
(Bug #16078557)
If the error for a failed CACHE
INDEX
statement index within a stored program was
processed by a condition handler, a malformed packet and
“Command out of sync” error occurred.
(Bug #16076180)
Setting the
slave_rows_search_algorithms
system variable to an inappropriate value could cause the server
to exit.
(Bug #16074161)
SET PASSWORD
and
GRANT ... IDENTIFIED
BY
have no effect on the password of a user who is
authenticated using an authentication plugin that accesses
passwords stored externally to the mysql.user table. But
attempts to change the password of such a user produced no
warning, leading to the impression that the password had been
changed when it was not. Now MySQL issues an
ER_SET_PASSWORD_AUTH_PLUGIN
warning to indicate that the attempt was ignored.
(Bug #16072004)
Directory name manipulation could result in stack overflow on OS X and Windows. (Bug #16066243)
References to the unused
SIGNAL_WITH_VIO_SHUTDOWN
macro in the
CMake files were removed.
(Bug #16066150)
The initial test
database contained a
dummy.bak
file that prevented DROP
DATABASE
from working. This file is no longer
included. Also, a db.opt
file is now included
that contains these lines:
default-character-set=latin1 default-collation=latin1_swedish_ci
(Bug #16062056)
Issuing a PREPARE
statement using certain
combinations of stored functions and user variables caused the
server to exit.
(Bug #16056537)
Setting a system variable to DEFAULT
could
cause the server to exit.
(Bug #16044655)
For debug builds, if the server was started with binary logging
disabled, executing SHOW RELAYLOG
EVENTS
from within a stored procedure raised an
assertion.
(Bug #16043173)
The query parser leaked memory for some syntax errors. (Bug #16040022)
During shutdown, the server could attempt to lock an uninitialized mutex. (Bug #16016493)
The --default-authentication-plugin
option
permitted invalid plugin values, and did not always set the
old_passwords
system variable to a value
appropriate for the named plugin.
(Bug #16014394)
Instances of #ifdef
WITH_MYISAMMRG_STORAGE_ENGINE
and #ifdef
WITH_CSV_STORAGE_ENGINE
in the server source code were
removed because the CSV
and
MERGE
storage engine plugins are mandatory.
(Bug #15997345)
The --character-set-server
option
could set connection character set system variables to values
such as ucs2
that are not permitted.
(Bug #15985752, Bug #23303391)
For debug builds, executing a statement within a trigger or stored function that caused an implicit commit raised an assertion. (Bug #15985318)
Under some circumstances, mysql --secure-auth permitted passwords to be sent to the server using the old (pre-4.1) hashing format. (Bug #15977433)
A mysys
library string-formatting routine
could mishandle width specifiers.
(Bug #15960005)
Table creation operations added entries to the
file_instances
Performance Schema
table, but these were not always removed for table drop
operations.
(Bug #15927620)
With index condition pushdown enabled, queries for which the pushed-down condition contained no columns in the used index could be slow. (Bug #15896009)
A query with an EXISTS/IN/ALL/ANY
subquery
with an ORDER BY
clause ordering by an outer
column of type BLOB
that is not in the select
list caused an assertion to fire.
(Bug #15875919)
References: See also: Bug #14728142.
In special cases, the optimizer did not consider indexes that
were applicable to query processing, resulting in potentially
suboptimal execution and incorrect
EXPLAIN
output.
(Bug #15849135, Bug #16094171)
Queries in the query cache involving a given table were
incorrectly invalidated if a TEMPORARY
table
of the same name was dropped.
(Bug #14839743)
The optimizer could return nonmatching records for queries that
used ref
access on string
data types.
(Bug #14826522)
References: See also: Bug #14682735.
Failure of CREATE SERVER
due to a
missing or read-only mysql.servers
table
resulted in a memory leak.
(Bug #14781478)
Table names can be up to 64 characters, but the message string
for the ER_TABLE_NEEDS_REBUILD
and ER_TABLE_NEEDS_UPGRADE
errors were truncating names longer than 32 characters.
(Bug #14753226)
Enabling the query cache during high client contention could cause the server to exit. (Bug #14727815)
Enabling the slow query log at runtime when access permissions on the log file prevented the server from writing to it caused the server to exit. (Bug #14711347)
If the optimizer calculated a row count of zero for the inner table of an outer join, it could not determine proper ordering for the following tables. (Bug #14628746)
The server sometimes failed to respect
MAX_CONNECTIONS_PER_HOUR
limits on user
connections.
(Bug #14627287)
The server could access the DEBUG_SYNC
facility while closing temporary tables during connection
shutdown, after the facility had been cleaned up, leading to an
assertion being raised.
(Bug #14626800)
The optimizer could return incorrect results after transforming
an IN
subquery with aggregate functions to an
EXISTS
subquery.
(Bug #14586710)
Table removal could fail and cause the server to exit for very long file names. (Bug #14581920)
When a client program loses the connection to the MySQL server
or if the server begins a shutdown after the client has executed
mysql_stmt_prepare()
, the next
mysql_stmt_prepare()
returns an
error (as expected) but subsequent
mysql_stmt_execute()
calls crash
the client.
(Bug #14553380)
Previously, if multiple --login-path
options
were given, mysql_config_editor ignored all
but the last one. Now multiple --login-path
options result in an error.
(Bug #14551712)
If MySQL server was started with options to enable the general query log or slow query log, but access permissions on the log file prevented the server from writing to it, the server started with an error message indicating that logging was off and that the server needed to be restarted after the problem was corrected. This was incorrect because it is also possible to set the logging variables again at runtime (without a restart) after correcting the problem. The error message now indicates this possibility. (Bug #14512467)
For debug builds, creating a TEMPORARY
table
inside a trigger caused the server to exit.
(Bug #14493938)
SHOW COLUMNS
on a view defined as
a UNION
of
Geometry
columns could cause the server to
exit.
(Bug #14362617)
The
sha256_password_private_key_path
and
sha256_password_public_key_path
system variables indicate key files for the
sha256_password
authentication plugin, but
the server failed to properly check whether the key files were
valid. Now in the event that either key file is invalid, the
server logs an error and exits.
(Bug #14360513)
SET
could
cause the server to exit. This syntax is now prohibited because
in var_name
=
VALUES(col_name
)SET
context there is no column name and
the statement returns
ER_BAD_FIELD_ERROR
.
(Bug #14211565)
The COM_CHANGE_USER
command in the
client/server protocol did not properly use the character set
number in the command packet, leading to incorrect character set
conversion of other values in the packet.
(Bug #14163155)
If the server was started with
--skip-grant-tables
, the
CREATE EVENT
and
ALTER EVENT
statements resulted
in a memory leak.
(Bug #14059662)
Invoking the FORMAT()
function
with a locale and a very large number could cause the server to
exit.
(Bug #14040155)
For debug builds, improper handling for
AUTO_INCREMENT
value overflow could cause the
server to exit.
(Bug #13875572)
Certain plugin-related conditions can make a user account unusable:
The account requires an authentication plugin that is not loaded.
The account requires the sha256_password
authentication plugin but the server was started with
neither SSL nor RSA enabled as required by this plugin.
The server now checks those conditions by default and produces
warnings for unusable accounts. This checking slows down server
initialization and FLUSH PRIVILEGES
, so it is
made optional by means of the new
validate_user_plugins
system variable. This
variable is enabled by default, but if you do not require the
additional checking, you can disable it at startup to avoid the
performance decrement.
(Bug #13010061, Bug #14506305)
Passing an unknown time zone specification to
CONVERT_TZ()
resulted in a memory
leak.
(Bug #12347040)
The obsolete linuxthreads.txt
and
glibc-2.2.5.patch
files in the
Docs
directory of MySQL distributions have
been removed.
(Bug #11766326)
The server could exit if built to permit a maximum number of indexes per table larger than 64.
In the course of fixing this problem, a
-DMAX_INDEXES=
CMake option was added to permit building the
server to support a larger maximum number of indexes per table.
The default is 64. The maximum is 255. Values smaller than 64
are ignored and the default of 64 is used.
(Bug #11761614)N
mysql_install_db did not escape
'_'
in the host name for statements written
to the grant tables.
(Bug #11746817)
With
explicit_defaults_for_timestamp
enabled, inserting NULL
into a
TIMESTAMP NOT NULL
column now produces an
error (as it already did for other NOT NULL
data types), instead of inserting the current timestamp.
(Bug #68472, Bug #16394472)
Handling of SQL_CALC_FOUND_ROWS
in
combination with ORDER BY
and
LIMIT
could lead to incorrect results for
FOUND_ROWS()
.
(Bug #68458, Bug #16383173)
If INET6_NTOA()
or
INET6_ATON()
returned
NULL
for a row in a result set, following
rows also returned NULL
.
(Bug #68454, Bug #16373973)
A statement with an aggregated, nongrouped outer query and an
aggregated, nongrouped subquery in the SELECT
list could return incorrect results.
(Bug #68372, Bug #16325175)
Adding an ORDER BY
clause following an
IN
subquery could cause duplicate rows to be
returned.
(Bug #68330, Bug #16308085)
If the server was started with
--skip-grant-tables
,
ALTER USER ... PASSWORD EXPIRE
caused the
server to exit.
(Bug #68300, Bug #16295905)
Configuring with -DWITH_SSL=/path/to/openssl
resulted in link errors due to selection of the incorrect
libcrypto
.
(Bug #68277, Bug #16284051)
If mysql is built with the bundled
libedit
library, the library is built as
static code, to avoid linking to a different dynamic version at
runtime. Dynamic linking could result in use of a different,
incompatible version and a segmentation fault.
(Bug #68231, Bug #16296509)
Some table I/O performed by the server when calling a storage engine were missing from the statistics collected by the Performance Schema. (Bug #68180, Bug #16222630)
The Perl version of mysql_install_db mishandled some error messages. (Bug #68118, Bug #16197542)
For arguments with fractional seconds greater than six decimals,
SEC_TO_TIME()
truncated, rather
than rounding as it should have.
(Bug #68061, Bug #16093024)
Queries with many values in a IN()
clause
were slow due to inclusion of debugging code in non-debugging
builds.
(Bug #68046, Bug #16078212)
References: See also: Bug #58731, Bug #11765737.
ALTER TABLE
inserted
tbl_name
ADD
COLUMN col_name
TIMESTAMP DEFAULT
CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP0000-00-00 00:00:00
rather than the current
timestamp if the alteration was done in place rather than by
making a table copy.
(Bug #68040, Bug #16076089)
mysqld_safe used the nonportable
-e
test construct.
(Bug #67976, Bug #16046140)
The server did not enforce the
port
or
report_port
upper limit of
65,535 and truncated larger values.
(Bug #67956, Bug #16035522)
Nonspatial indexes only support exact-match lookups for spatial
columns, but the optimizer incorrectly used
range
access in some cases,
leading to incorrect results.
(Bug #67889, Bug #15993693)
For EXPLAIN DELETE
and EXPLAIN
UPDATE
the possible_keys
column
listed all indexes, not just the applicable indexes.
(Bug #67830, Bug #15972078)
SLEEP()
produced no warning or
error for NULL
or negative arguments. Now it
produces a warning, or an error in strict SQL mode.
(Bug #67548, Bug #15859462)
Attempts to create a trigger for which a trigger with the same
action time and event already existed resulted in an
ER_NOT_SUPPORTED_YET
error
rather than an
ER_TRG_ALREADY_EXISTS
error.
(Bug #67357, Bug #14801721)
If a table had rows in the
INFORMATION_SCHEMA.INNODB_CMP_PER_INDEX
table, dropping the table did not remove those rows.
(Bug #67283, Bug #14779330)
MySQL failed to build if configured with
WITH_LIBWRAP
enabled.
(Bug #67018, Bug #16342793)
If one thread was rebuilding a result for the query cache, other threads in the middle of using the previous result could fail to discard the old result properly. For debug builds, this raised an assertion. (Bug #66781, Bug #14631798)
CMake did not check whether the system
zlib
had certain functions required for
MySQL, resulting in build errors. Now it checks and falls back
to the bundled zlib
if the functions are
missing.
(Bug #65856, Bug #14300733)
If a dump file contained a view with one character set and collation defined on a view with a different character set and collation, attempts to restore the dump file failed with an “illegal mix of collations” error. (Bug #65382, Bug #14117025)
The SQL_NO_CACHE
keyword is supposed to
prevent the server from checking the query cache to see whether
the query result is already cached, and to prevent it from
caching the query result. However, the query cache check was
suppressed only if SQL_NO_CACHE
was preceded
and followed by space characters. (For example, the server
checked the cache if the keyword was followed by a newline.) Now
the parser requires that the preceding and following characters
be whitespace characters, not spaces.
(Bug #64164, Bug #13641256)
If the server was started without a
--datadir
option,
SHOW VARIABLES
could show an
empty value for the datadir
system variable.
(Bug #60995, Bug #12546953)
When a view definition contained a special character in the
SEPARATOR
clause of the
GROUP_CONCAT()
aggregate
function, mysqldump created an invalid view
definition that produced an error when the dump file was
reloaded.
(Bug #60920, Bug #12395512)
For debug builds, some queries with SELECT ... FROM
DUAL
nested subqueries raised an assertion.
(Bug #60305, Bug #11827369)
The --log-slow-admin-statements
and
--log-slow-slave-statements
command options now
are exposed at runtime as the
log_slow_admin_statements
and
log_slow_slave_statements
system variables.
Their values can be examined using SHOW
VARIABLES
. The variables are dynamic, so their values
can be set at runtime. (The options were actually
replaced by the system variables, but as
system variables can be set at server startup, no option
functionality is lost.)
(Bug #59860, Bug #11766693)
Source code in the mysys
library for the
my_malloc_lock
and
my_free_lock
memory-locking APIs was never
used and has been removed.
(Bug #54662, Bug #11762107)
If the server failed to read errmsg.sys
, it
could exit with a segmentation fault.
(Bug #53393, Bug #11760944)
UNION ALL
on
BLOB
columns could produce
incorrect results.
(Bug #50136, Bug #11758009)
An out-of-memory condition could occur while handling an out-of-memory error, leading to recursion in error handling. (Bug #49514, Bug #11757464)
The REPLACE()
function produced
incorrect results when a user variable was supplied as an
argument and the operation was performed on multiple rows.
(Bug #49271, Bug #11757250)
UNION
type conversion could
incorrectly turn unsigned values into signed values.
(Bug #49003, Bug #11757005)
If XA support was activated by multiple storage engines, the server would exit. (Bug #47134, Bug #11755370)
Use of KILL
to kill a statement
in another session could in some cases cause that session to
return an incorrect error code.
(Bug #45679, Bug #11754124)
Setting max_connections
to a
value less than the current number of open connections caused
the server to exit.
(Bug #44100, Bug #11752803)
The optimizer used Loose Index Scan for some queries for which this access method is inapplicable. (Bug #42785, Bug #11751794)
View access in low memory conditions could raise a debugging assertion. (Bug #39307, Bug #11749556)
The output for SHOW CREATE VIEW
could vary depending on the DEFINER
account
privileges.
(Bug #34553, Bug #11747931)
If a column is declared as NOT NULL
, it is
not permitted to insert NULL
into the column
or update it to NULL
. However, this
constraint was enforced even if there was a BEFORE
INSERT
(or BEFORE UPDATE
trigger)
that set the column to a non-NULL
value. Now
the constraint is checked at the end of the statement, per the
SQL standard.
(Bug #6295, Bug #11744964, WL #6030)