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.)
Important Change; Microsoft Windows: MySQL builds on Windows using Visual Studio now require Visual Studio 2013 or later. The previous requirement was Visual Studio 2010 or later. (Bug #18404381)
Important Change: The atomic-operations API was simplified to use only the existing GCC built-in implementation or platform-provided implementations (for Windows, Solaris), and to remove the custom mutex-based fallback implementation. The retained implementations are those able to use CPU-native atomics. This simplifies the atomics APIs and related code and deals with bugs resulting from the fallback implementation.
As part of this work, the (undocumented)
WITH_ATOMIC_LOCKS
and
MY_ATOMIC_MODE_RWLOCKS
CMake
options were removed.
On platforms where native atomics are supported, this change introduces no issues. For other platforms, here are potential MySQL compilation issues, and solutions:
32-bit Linux variants that use GCC 4.1 will no longer work.
This includes Red Hat 5, which is a supported platform. The
solution to this problem is to use a new GCC or set the
-march
compiler option. For example, use
GCC 4.4, which is available on Red Hat 5. For information
about specifying compiler options, see
Compiler Flags.
There may be issues on unsupported platforms. For example, 64-bit PowerPC, 32-bit ARM, and 64-bit ARM will not compile with older compilers. The solution for these cases is to use GCC 4.7 or later.
CMake now checks for minimum versions of
supported compilers: gcc 4.4 (Linux,
Solaris); Sun Studio 12u2 (Solaris client library); Clang 3.3
(OS X, FreeBSD). This check can be disabled with the
-DFORCE_UNSUPPORTED_COMPILER=ON
option.
(Bug #19187034)
Noisy compiler warnings on FreeBSD 10 were silenced. (Bug #18790490)
CMake workarounds for older OS X and XCode versions were removed. On OS X, compilation always uses Clang, even for 32-bit builds.
Compilation on OS X is now supported for OS X 10.8 and up, using XCode 5 and up. Compilation on older versions may work but is unsupported. (Bug #18510941)
Previously, the
MYSQL_MAINTAINER_MODE
CMake option was turned on by default for
debug builds and off for release builds, and
MYSQL_MAINTAINER_MODE
caused
-Werror
to be enabled when building with GCC.
This made it cumbersome to enable -Werror
under
certain conditions, such as when compiling with Clang.
Now, MYSQL_MAINTAINER_MODE
is on by default
when compiling debug builds with GCC, and
MYSQL_MAINTAINER_MODE
enbles
-Werror
regardless of whether GCC or Clang is
used. Enabling -Werror
with Clang can be done
simply by explicitly setting
-DMYSQL_MAINTAINER_MODE=1
when running
CMake. In addition, some compilation warnings
reported by Clang 3.4 were fixed, making it possible to build
the default debug build with -Werror
.
(Bug #18313717)
Build support was modified to produce the same warnings for Clang as for gcc. (Bug #17959689)
Work was done to clean up the source code base, including: Removing unneeded CMake checks; removing unused macros from source files; reorganizing header files to reduce the number of dependencies and make them more modular, removing function declarations without definitions, replacing locally written functions with equivalent functions from industry-standard libraries.
Incompatible Change: mysql_install_db has been rewritten from Perl into C++. This enables it to be provided as an executable binary and eliminates its dependency on having Perl installed.
The new implementation involves several other differences as well. The following items list some of the most significant changes. For more information, see mysql_install_db — Initialize MySQL Data Directory.
The executable binary version is located in the
bin
installation directory, whereas the
Perl version was located in the scripts
installation directory. For upgrades from an older version
of MySQL, you may find a version of
mysql_install_db in both directories. To
avoid confusion, remove the version from the
scripts
directory. For fresh
installations of MySQL 5.7.5 or later,
mysql_install_db is only found in the
bin
directory, and the
scripts
directory is no longer present.
Applications that expect to find
mysql_install_db in the
scripts
directory should be updated to
look in the bin
directory instead.
Some options are handled differently. For example, the
--datadir
option is
mandatory.
There are several new options. For example, there are
options that afford explicit control over the administrative
account that is created. By default, this is
'root'@'localhost'
, but you can use
--admin-user
and
--admin-host
to
change the user and host parts of the account name.
Several options have been removed or replaced. For example,
--skip-random-passwords
has been replaced
by --insecure
.
mysql_install_db always overwrites the
.mysql_secret
file, rather than
appending to it if it exists. It is assumed that immediately
after installation, you will connect to the server using the
file contents and reset the administrative password before
proceeding to another deployment.
mysql_install_db no longer passes
unrecognized options to mysqld. (But you
can use
--defaults-extra-file
to specify an option file to be added to the
mysqld bootstrapping command.)
mysql_install_db no longer creates a
default my.cnf
file.
MySQL now includes DTrace support on Oracle Linux 6 or higher with UEK kernel. If DTrace is present, server builds will detect it with no special CMake options required. For information about using DTrace on MySQL, see Tracing mysqld Using DTrace.
The server was made more consistent and resilient with regard to
handling of statements for which the IGNORE
keyword is specified.
The server failed to report warnings for INSERT
IGNORE
statements.
The server could fail to report warnings for multiple-table
DELETE IGNORE
statements.
UPDATE
triggers for a table were invoked
even for UPDATE IGNORE
statements for
which a unique index caused the update to be ignored.
For debug builds, an assertion could be raised for errors
occurring in DELETE IGNORE
statements.
For debug builds, an assertion could be raised for deadlocks
resulting from DELETE IGNORE
statements.
For DELETE IGNORE
executed on the parent
table in a foreign key relationship, foreign key violation
errors were treated as warnings (correct), but rows that did
not produce foreign key violations were not deleted.
The server was made more consistent and resilient with regard to handling of statements in strict SQL mode.
In strict SQL mode, triggers could permit operations not permitted in strict mode.
In strict SQL mode, deprecation warnings about duplicate indexes were incorrectly promoted to errors.
Strict SQL mode was not applied to multiple-table
DELETE
statements.
For more information about IGNORE
and strict
SQL mode, see Comparison of the IGNORE Keyword and Strict SQL Mode.
(Bug #6196, Bug #11744960, Bug #43895, Bug #11752648, Bug #68726, Bug #16522924, Bug #16860715, Bug #16860829, Bug #14786621, Bug #17550423, Bug #42910, Bug #11751889, Bug #16976939, Bug #18526888)
Incompatible Change:
The InnoDB
storage engine can no longer be
disabled. The
--skip-innodb
option is deprecated and has no effect, and its use results in a
warning. It will be removed in a future MySQL version. This also
applies to its synonyms (--innodb=OFF
,
--disable-innodb
, and so forth).
A new innodb_lock_no_retry
flag for the
--debug
option is now available.
--debug='d,innodb_lock_no_retry'
causes
InnoDB
to fail immediately during startup if
locks cannot be acquired, rather than making 100 attempts before
failing. This may be useful during testing or debugging to
produce faster server exit when InnoDB
cannot
acquire its locks.
One reason for disabling InnoDB
is to enable
starting a server instance using the same data directory as an
existing instance. (MyISAM
permits that, but
InnoDB
does not.) Because
InnoDB
can no longer be disabled, the
workaround is to stop the existing instance before starting
another so that there is only one active instance using a data
directory at a time.
Incompatible Change:
A new log record type (MLOG_FILE_NAME
) is
used to identify file-per-table tablespaces that have been
modified since the last checkpoint. This enhancement simplifies
tablespace discovery during crash recovery and eliminates scans
on the file system prior to redo log application. For more
information about the benefits of this enhancement, see
Tablespace Discovery During Crash Recovery.
This enhancement changes the redo log format, requiring that MySQL be shut down cleanly before upgrading to or downgrading from MySQL 5.7.5.
The optimizer computes more accurate costs for semijoin materialization. (Bug #18558561)
Optimizer trace output for range access in the
considered_access_path
section has been
improved: Instead of always printing "access_type":
"ref"
for index lookup types,
"eq_ref"
, "ref"
, or
"fulltext"
is now printed.
(Bug #18195373)
During query execution plan construction, the optimizer now can
use condition filtering to better use conditions on a table in
estimating the number of qualifying rows to join to the next
table. For example, even though there might be an index-based
access method that can be used to select rows from the current
table in a join, there might also be additional conditions for
the table in the WHERE
clause that can filter
(further restrict) the estimate for qualifying rows passed to
the next table.
To control whether the optimizer considers additional filtering
conditions, use the
condition_fanout_filter
flag
of the optimizer_switch
system
variable. This flag is enabled by default but can be disabled to
suppress condition filtering (for example, if a particular query
is found to yield better performance without it).
For more information, see Condition Filtering.
The optimizer now uses more exact index statistics. Currently,
the improved values are used by InnoDB
, with
these effects:
In many cases, better execution plans result for queries for which previously a less optimal join index or table join order was chosen.
The row estimates in EXPLAIN
output are more accurate, as well as the filter values in
some cases.
Cardinality estimates in the index statistics displayed by
SHOW INDEX
are more accurate
for InnoDB
tables.
To generate execution plans, the optimizer uses a cost model that is based on estimates of the cost of various operations that occur during query execution. The optimizer has a set of compiled-in default “cost constants” available to it to make decisions regarding execution plans.
The optimizer now also has a database of cost estimates to use
during execution plan construction. These estimates are stored
in the server_cost
and
engine_cost
tables in the
mysql
system database and are configurable at
any time: Any non-NULL
cost estimate stored
in the cost model tables overrides the corresponding compiled-in
default estimate. Any NULL
estimate indicates
to the optimizer to use the compiled-in default.
Implementation and testing is ongoing to make it safe for DBAs to change these values. Currently, changing them should be considered at your own risk.
There is also a new FLUSH
variant, FLUSH OPTIMIZER_COSTS
, that causes
the server to reread the cost tables and apply any changed
estimates to new sessions.
For more information, see The Optimizer Cost Model.
If you upgrade to this MySQL release from an earlier version,
you must run mysql_upgrade (and restart the
server) to incorporate these changes into the
mysql
database.
Incompatible Change:
The Performance Schema now provides a
user_variables_by_thread
table that
exposes user-defined variables. For more information, see
Performance Schema User-Defined Variable Tables.
In consequence of this change, the server now limits
user-defined variable names to a maximum of 64 characters, the
length of the VARIABLE_NAME
column in the
table. Previously, the server did not enforce a limit. The new
limit is similar to the limit on the lengths of many other
identifiers in MYSQL (see User-Defined Variables).
Queries that use very long user-defined variable names must be
rewritten to user shorter names.
If you upgrade to this MySQL release from an earlier version,
you must run mysql_upgrade (and restart the
server) to incorporate this change into the
performance_schema
database.
Previously, for the wait event tables (such as
events_waits_current
), the
NUMBER_OF_BYTES
column was
NULL
for table I/O waits; that is, for events
for the wait/io/table/sql/handler
instrument.
For table I/O waits, this value now indicates the number of rows
processed.
In addition, for batch I/O operations (such as row fetches for
table or index scans), the Performance Schema now can report a
single event for N
rows, rather than
reporting a single-row event N
times.
This change significantly reduces Performance Schema overhead
for table batch I/O by reducing the number of reporting calls.
The tradeoff is lesser accuracy for event timing. Rather than
time for an individual row operation as in per-row reporting,
timing for batch I/O includes time spent for operations such as
join buffering, aggregation, and returning rows to the client.
For more information on the conditions under which batch I/O
reporting occurs, see the description of the
NUMBER_OF_BYTES
column in
The events_waits_current Table.
The Performance Schema stage event tables
(events_stages_current
,
events_stages_history
, and
events_stages_history_long
) contain
two new columns that, taken together, provide a stage progress
indicator for each row:
WORK_COMPLETED
: The number of work units
completed for the stage
WORK_ESTIMATED
: The number of work units
expected for the stage
Each column is NULL
if no progress
information is provided for an instrument. Interpretation of the
information, if it is available, is entirely up to the
instrument implementation. Initially, to demonstrate the
concept, the stage/sql/copy to tmp table
instrument provides progress information if it is enabled. In
this case, the unit for interpretation of the columns is number
of rows copied.
For more information, see Performance Schema Stage Event Tables.
If you upgrade to this MySQL release from an earlier version,
you must run mysql_upgrade (and restart the
server) to incorporate this change into the
performance_schema
database.
Incompatible Change: MySQL 5.6 deprecated passwords that used the older pre-4.1 password hashing format. Support for these passwords is now removed, which involves the following changes. Applications that use any feature no longer supported must be modified.
The server-side mysql_old_password
authentication plugin is removed. Accounts that use this
plugin are disabled at startup and the server writes an
“unknown plugin” message to the error log. For
instructions on upgrading accounts that use this plugin, see
Migrating Away from Pre-4.1 Password Hashing and the mysql_old_password Plugin.
The client-side mysql_old_password
authentication plugin is removed from the C client library.
The --secure-auth
option to the server and
client programs is the default, but is now a no-op. It is
deprecated and will be removed in a future MySQL version.
The --skip-secure-auth
option to the server
and client programs is no longer supported and using it
produces an error.
The secure_auth
system
variable permits only a value of 1; a value of 0 is no
longer permitted.
For the old_passwords
system variable, a value of 1 (produce pre-4.1 hashes) is no
longer permitted.
The OLD_PASSWORD()
function
is removed.
The mysqladmin
old-password
command is removed.
MySQL now includes a server-side authentication plugin named
mysql_no_login
for setting up accounts that
accept no client connections. This plugin enables DBAs to
implement the following use cases:
Stored program and view objects that perform sensitive or
adminstrative operations must run with elevated privileges.
Less-privileged users must be able to execute these objects
but not be able to directly log in as the account that has
the privileges. To implement this, create a no-login account
using mysql_no_login
, grant it the
required privileges, define objects with a
DEFINER
of that account, and include
SQL SECURITY DEFINER
in the definitions.
Access to a proxy account must always be by the usual proxy
mechanism, never by users logging in directly to the proxy
account. To implement this, assign
mysql_no_login
as the authentication
plugin when you create the proxy account.
For more information, see No-Login Pluggable Authentication.
MySQL distributions now attempt to deploy with SSL and RSA capabilities enabled by default.
To make it easier to support encrypted connections, MySQL servers compiled using OpenSSL now can automatically generate SSL and RSA files at startup if they are missing:
The server automatically generates server-side and
client-side SSL certificate and key files in the data
directory if the new
auto_generate_certs
system
variable is enabled, no SSL options other than
--ssl
are specified, and the
server-side SSL files are missing from the data directory.
These files enable encrypted client connections using SSL.
The server automatically generates RSA private/public
key-pair files in the data directory if the new
sha256_password_auto_generate_rsa_keys
system variable is enabled, no RSA options are specified,
and the RSA files are missing from the data directory. These
files enable secure password exchange using RSA over
unencrypted connections for accounts authenticated by the
sha256_password
plugin.
The server-side --ssl
option
value now is enabled by default for all servers. For servers
compiled using OpenSSL, if --ssl
is enabled and other SSL options are not given to configure SSL
explicitly, the server attempts to enable SSL automatically at
startup:
If the server finds valid SSL files named
ca.pem
,
server-cert.pem
, and
server-key.pem
in the data directory,
it enables SSL to permit SSL connections by clients. (These
files need not have been autogenerated; what matters is that
they have the indicated names and are valid.)
If the server does not find valid SSL files in the data directory, it continues executing but does not enable SSL.
For any SSL and RSA files that the server finds and uses
automatically, it uses the file names to set the corresponding
system variables (ssl_ca
,
ssl_cert
,
ssl_key
,
sha256_password_private_key_path
,
sha256_password_public_key_path
).
For more information, see Configuring MySQL to Use Encrypted Connections, and Creating SSL and RSA Certificates and Keys using MySQL.
InnoDB:
SPATIAL
indexes can now be used for
InnoDB
tables. InnoDB
supports indexing of spatial data types, including use of
ALTER TABLE ...
ALGORITHM=INPLACE
for online operations (ADD
SPATIAL INDEX
). To support transaction isolation
properties, InnoDB
uses predicate locking. A
predicate lock locks the minimum bounding rectangle (MBR) used
for a query so that other transactions cannot insert or modify a
row that would match the query condition.
For more information, see Optimizing Spatial Analysis. and Predicate Locks for Spatial Indexes. (Bug #18674219)
The Open Geospatial Consortium guidelines document the use of open polygons (polygons where the start point is not equal to the end point) but the MySQL GIS implementation did not support them. Now MySQL supports open polygons: An open polygon is converted to a closed one by appending the starting point to the point sequence. Before:
mysql> SELECT AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))'));
+---------------------------------------------------------------+
| AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))')) |
+---------------------------------------------------------------+
| NULL |
+---------------------------------------------------------------+
After:
mysql> SELECT AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))'));
+---------------------------------------------------------------+
| AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))')) |
+---------------------------------------------------------------+
| POLYGON((10 10,20 10,20 20,10 20,10 10)) |
+---------------------------------------------------------------+
(Bug #17168699)
GeometryCollection()
returned
NULL
if the argument contained nonsupported
geometries. Now
GeometryCollection()
returns all
the proper geometries contained in the argument even if a
nonsupported geometry is present.
(Bug #17168643)
This MySQL release makes increased use of the Boost.Geometry library to provide better reliability and increased functionality for spatial functions. As a result, several previously unimplemented functions have been implemented, and several previously existing functions now accept a wider range of geometry argument types (or argument type combinations for functions that take multiple geometries):
These previously unimplemented spatial operator functions
are now available:
ST_ConvexHull
,
ST_Difference()
,
ST_Intersection()
,
ST_SymDifference()
, and
ST_Union()
.
These previously existing functions are more robust and
return non-NULL
values for more geometry
argument types: ST_Area()
,
ST_Centroid()
,
ST_Contains()
,
ST_Crosses()
,
ST_Disjoint()
,
ST_Distance()
,
ST_Envelope()
,
ST_Equals()
,
ST_Intersects()
,
ST_Overlaps()
,
ST_Touches()
, and
ST_Within()
. These functions
also exist as non-ST_
synomyms; for
example, ST_Area()
and
Area()
are synonyms.
MySQL now includes functions for converting between GeoJSON
documents and spatial values:
ST_AsGeoJSON()
and
ST_GeomFromGeoJSON()
. For more
information, see Spatial GeoJSON Functions.
MySQL now includes functions that enable manipulation of geohash values, which provides applications the capabilities of importing and exporting geohash data, and of indexing and searching geohash values:
ST_GeoHash()
returns a
geohash string given a return value length and either
longitude and latitude values or a POINT
value.
ST_LongFromGeoHash()
and
ST_LatFromGeoHash()
return
the longitude or latitude value, respectively, given a
geohash string argument.
ST_PointFromGeoHash()
produces a POINT
value from a geohash
string argument.
Incompatible Change: These SQL mode changes were made:
Strict SQL mode for transactional storage engines
(STRICT_TRANS_TABLES
) is
now enabled by default.
Implementation of the
ONLY_FULL_GROUP_BY
SQL
mode has been made more sophisticated, to no longer reject
deterministic queries that previously were rejected.
MySQL now recognizes when a nonaggregated selected
column is functionally dependent on (uniquely determined
by) GROUP BY
columns.
MySQL has an extension to standard SQL that permits
references in the HAVING
clause to
aliased expressions in the select list. Previously,
enabling
ONLY_FULL_GROUP_BY
disables this extension, thus requiring the
HAVING
clause to be written using
unaliased expressions. This restriction has been lifted
so that the HAVING
clause can refer
to aliases regardless of whether
ONLY_FULL_GROUP_BY
is
enabled.
In consequence,
ONLY_FULL_GROUP_BY
is now
enabled by default, to prohibit nondeterministic queries
containing expressions not guaranteed to be uniquely
determined within a group.
The changes to the default SQL mode result in a default
sql_mode
system variable
value with these modes enabled:
ONLY_FULL_GROUP_BY
,
STRICT_TRANS_TABLES
,
NO_ENGINE_SUBSTITUTION
.
The ONLY_FULL_GROUP_BY
mode is now included in the modes comprised by the
ANSI
SQL mode.
A new function, ANY_VALUE()
, is available
that can be used to force MySQL to accept queries that it
thinks should be rejected with
ONLY_FULL_GROUP_BY
enabled. The function return value and type are the same as
the return value and type of its argument, but the function
result is not checked for the
ONLY_FULL_GROUP_BY
SQL
mode.
If you find that having
ONLY_FULL_GROUP_BY
enabled
causes queries for existing applications to be rejected, either
of these actions should restore operation:
If it is possible to modify an offending query, do so,
either so that nondeterministic nonaggregated columns are
functionally dependent on GROUP BY
columns, or by referring to nonaggregated columns using
ANY_VALUE()
.
If it is not possible to modify an offending query (for
example, if it is generated by a third-party application),
set the sql_mode
system variable at
server startup to not enable
ONLY_FULL_GROUP_BY
.
For more information about SQL modes and GROUP
BY
queries, see Server SQL Modes, and
MySQL Handling of GROUP BY.
(Bug #18486310)
Incompatible Change:
The GET_LOCK()
function has been
reimplemented using the metadata locking (MDL) subsystem and its
capabilities have been extended:
Previously, GET_LOCK()
permitted acquisition of only one named lock at a time, and
a second GET_LOCK()
call
released any existing lock. Now
GET_LOCK()
permits
acquisition of more than one simultaneous named lock and
does not release existing locks.
Applications that rely on the behavior of
GET_LOCK()
releasing any
previous lock must be modified for the new behavior.
The capability of acquiring multiple locks introduces the
possibility of deadlock among clients. The MDL subsystem
detects deadlock and returns an
ER_USER_LOCK_DEADLOCK
error
when this occurs.
The MDL subsystem imposes a limit of 64 characters on lock names, so this limit now also applies to named locks. Previously, no length limit was enforced.
Locks acquired with
GET_LOCK()
now appear in the
metadata_locks
Performance
Schema table. The OBJECT_TYPE
column says
USER LEVEL LOCK
and the
OBJECT_NAME
column indicates the lock
name.
A new function,
RELEASE_ALL_LOCKS()
permits
release of all acquired named locks at once.
For more information, see Locking Functions.
Incompatible Change:
In MySQL 5.6.6, the YEAR(2)
data
type was deprecated. Support for
YEAR(2)
has now been removed.
Once you upgrade to MySQL 5.7.5 or newer, any remaining
YEAR(2)
columns must be converted
to YEAR(4)
to become usable
again. For conversion strategies, see
2-Digit YEAR(2) Limitations and Migrating to 4-Digit YEAR. For example, run
mysql_upgrade after upgrading.
Incompatible Change: Previously, mysql_upgrade performed an upgrade by invoking the mysql and mysqlcheck clients. mysql_upgrade has been reimplemented to generate the required SQL statements itself and execute them by communicating directly with server.
In consequence of this change, mysql_upgrade
now supports the
--bind-address
option
enabling the network interface for connecting to the server to
be chosen. It also supports
--net-buffer-length
and
--max-allowed-packet
options enabling the initial and maximum communication packet
size to be specified.
Also in consequence of this change,
mysql_upgrade no longer supports the
--tmpdir
option. This option specified the
location of temporary files used to supply input to
mysql, but it no longer has any purpose
because mysql_upgrade no longer invokes
mysql. Any upgrade scripts that invoke
mysql_upgrade and use
--tmpdir
must be modified to remove that
option.
InnoDB:
For optimal shutdown and recovery performance, shutdown and
recovery phases are now supported by the multithreaded page
cleaner feature
(innodb_page_cleaners
) that was
introduced in MySQL 5.7.4.
(Bug #18805275)
InnoDB:
Work was done to introduce the notion of attachable transactions
in InnoDB
(for AutoCommit / ReadOnly /
ReadCommitted / NonLocking transactions). This is used to read
from InnoDB
Data Dictionary tables. Along
with this, attachable transactions were exposed to the server.
Data Dictionary access code will use them to read Data
Dictionary data.
InnoDB:
You can now truncate undo logs that reside in undo tablespaces.
This feature is enabled using the
innodb_undo_log_truncate
configuration option. For more information, see
Truncating Undo Tablespaces.
InnoDB:
InnoDB
memory allocations now are
instrumented for the
Performance Schema and
will appear in the memory
summary tables.
InnoDB:
Instead of inserting one index record at a time,
InnoDB
now performs a bulk load when creating
or rebuilding indexes. This method of index creation is also
known as a sorted index build. This enhancement, which improves
the efficiency of index creation, also applies to full-text
indexes. It is not supported with spatial indexes.
A new global configuration option,
innodb_fill_factor
, defines the
percentage of space on each page that is filled with data during
a sorted index build, with the remaining space reserved for
future index growth. For more information, see
Sorted Index Builds.
InnoDB:
The FIL_PAGE_FLUSH_LSN
field, written to the
first page of each InnoDB
system tablespace
file and to InnoDB
undo tablespace files, is
now only written to the first file of the
InnoDB
system tablespace (page number 0:0).
As a result of this patch, if you have a multiple-file system
tablespace and decide to downgrade from MySQL 5.7 to MySQL 5.6,
you may encounter an invalid message on MySQL 5.6 startup
stating that the log sequence numbers
x
and y
in
ibdata files do not match the log sequence number
y
in the ib_logfiles. If
you encounter this message, restart MySQL 5.6 to ensure that
startup has run properly. The invalid message should no longer
appear.
InnoDB:
The innodb_buffer_pool_size
parameter is now dynamic, allowing you to resize the buffer pool
without restarting the server. The resizing operation, which
involves moving pages to a new location in memory, is performed
chunks. Chunk size is configurable using the new
innodb_buffer_pool_chunk_size
configuration option. You can monitor resizing progress using
the new
Innodb_buffer_pool_resize_status
status variable. For more information, see
Configuring InnoDB Buffer Pool Size Online.
See Configuring InnoDB Buffer Pool Size Online for more information.
Replication:
When replicating from a master running a version earlier than
MySQL 5.6.0 to a slave running MySQL 5.6.0 or later, the slave
requires the master_uuid
value, which is the
server_uuid
value from the
master. The master_uuid
value is unsupported
on the older master, and in such a replication situation could
become invalid on the newer slave. A check for empty
master_uuid
now ensures that the slave uses
an empty value for master_uuid
.
(Bug #18338203)
Replication:
Retrying of transactions is now supported when multithreading is
enabled on a slave. In previous versions,
slave_transaction_retries
was
treated as equal to 0 when using multithreaded slaves.
(Bug #16390504, Bug #68465)
Replication:
Global transaction identifiers (GTIDs) are now logged in a MySQL
system table whenever they are enabled on the server, which
lifts a previous requirement to use binary logging when
replicating with GTIDs. If binary logging is disabled, the
server stores the GTID for each transaction in the
mysql.gtid_executed
table as the transaction
is executed. If binary logging is enabled, then, whenever the
binary log is rotated or the server is shut down, the server
also writes into the new binary log the GTIDs for all
transactions from the previous binary log.
Because the mysql.gtid_executed
table can
become filled with many rows with single-transaction GTIDs
having the same originating server and sequential transaction
IDs, the server compresses this table periodically whenever
GTIDs are enabled. You can control the frequency with which the
table is compressed by setting the
executed_gtids_compression_period
system
variable. This variable's default value is 1000, which means
that compression of the table is applied following each 1000
transactions. You can set the
executed_gtids_compression_period
to 0 to
disable the compression altogether, but you should be aware that
doing this may cause the space required by this table to
increase significantly. (See
mysql.gtid_executed Table Compression.)
Compression of the mysql.gtid_executed table is performed by a
dedicated thread. You can obtain information about the state of
this thread in the threads
Performance Schema table.
(Bug #14730192)
Replication:
The new variable
simplified_binlog_gtid_recovery
can be used to change the way binary log files are searched for
previous GTIDs during recovery, speeding up the process when a
large number of binary log files exist.
(Bug #69097, Bug #16741603, Bug #74071, Bug #19686914)
Replication:
The new system variable
binlogging_impossible_mode
controls what happens if the server cannot write to the binary
log, for example, due to a file error. For backward
compatibility, the default for
binlogging_impossible_mode
is
IGNORE_ERROR
, meaning the server logs the
error, halts logging, and continues updates to the database.
Setting this variable to ABORT_SERVER
makes
the server halt logging and shut down if it cannot write to the
binary log.
(Bug #51014, Bug #11758766)
Replication:
To make monitoring of a replication setup easier, various
replication related variables have been moved to the
performance_schema
tables. This is
particularly helpful for monitoring multi-source replication.
Replication:
The new SQL function
WAIT_FOR_EXECUTED_GTID_SET()
makes the current syncing option for the slave with master
independent of the slave threads and improves the return value.
Replication:
The new options
binlog_group_commit_sync_delay
and
binlog_group_commit_sync_no_delay_count
provide a way to configure the synchronization of the binary
log. This enables more transactions to be synchronized together
to disk at once, reducing the overall time to commit a group of
transactions because the larger groups require fewer time units
per group.
Replication:
Multithreaded slaves can use the new
slave_preserve_commit_order
variable to ensure that the order which transactions were
committed on the master is preserved on the slave. This prevents
the slave from entering a state that the master was not in and
is well suited to using multithreaded slaves for replication
read scale-out.
New Debian7, Ubuntu12.04, and Ubuntu14.04 distribution support
that was introduced with 5.6.17 now comes with the
platform-specific packaging source placed under the
packaging
directory, in the
deb-precise
,
deb-wheezy
, and
deb-trusty
directories.
(Bug #19020385)
CMake support was updated to handle CMake version 3. (Bug #19001781)
The rwlock used for the SAFE_HASH
implementation is now instrumented for the Performance Schema.
The instrument name is
wait/synch/rwlock/mysys/SAFE_HASH::lock
.
(Bug #18991366)
The (undocumented) binary-configure.sh script has been removed from MySQL distributions. (Bug #18694238)
RHEL 4 is not supported for 5.7, so the
support-files/RHEL4-SElinux
file was
removed.
(Bug #18651087)
The (undocumented) FEATURE_SET
CMake option was removed.
(Bug #18521389)
Unused private fields reported by Clang's
-Wunused-private-field
compiler warning option
were removed.
(Bug #18489724)
thr_alarm.h
and
thr_alarm.c
were removed because they
contain dead code almost exclusively. The remaining live code
was moved to mysqld.cc
.
my_alarm.h
and
my_alarm.c
were also removed, and the code
from them that is actually used was moved to
my_lock.c
.
(Bug #18411456)
The deprecated timed_mutexes
system variable has been removed.
(Bug #18277305)
CMake support was updated to handle the new directory layout for Sun C++ 5.13. (Bug #73034, Bug #19010286)
The obsolete and unmaintained charset2html utility has been removed from MySQL distributions. (Bug #71897, Bug #18352347)
mysqld help text for
--general_log
was clarified. Thanks to Andrew
Gaul for the patch.
(Bug #71463, Bug #18127243)
The fill_help_tables.sql
file that is used
to load server-side help table content now contains the
following statement to suppress binary logging and prevent table
contents from replicating to slaves:
SET sql_log_bin=0;
Because help table content is specific to the a particular server version, this prevents loading incorrect content into the slaves, which do not necessarily run the same version of MySQL as the master. (Bug #69564, Bug #17015822)
The empty string provided for numeric or enumeration options
(for example, --port=""
) produced inconsistent
or confusing behavior. Such empty option values now are rejected
with an error.
(Bug #68055, Bug #16102788)
The mysqladmin flush-logs command now permits
optional log types to be given, to specify which logs to flush.
Following the flush-logs
command, you can
provide a space-separated list of one or more of the following
log types: binary
, engine
,
error
, general
,
relay
, slow
. These
correspond to the log types that can be specified for the
FLUSH LOGS
SQL statement. Thanks
to Daniël van Eeden for the patch.
(Bug #60878, Bug #12368203)
A new status variable,
Max_used_connections_time
,
indicates the time at which
Max_used_connections
reached
its current value. Thanks to Jordi Prats for the patch.
(Bug #59738, Bug #11766596)
Previously, on Unix and Unix-like systems, MySQL support for
sending the server error log to syslog
was
implemented by having mysqld_safe capture
server error output and pass it to syslog
.
The server now includes native syslog
support, which has been extended to include Windows. Server
error logging to syslog
, Event Log, or a
file, should be controlled using mysqld
options. Doing so using mysqld_safe options
is now deprecated. For more information about sending server
error output to syslog
, see
The Error Log.
In addition, system log output control is distinct from sending
error output to a file or the console, on all platforms.
Previously, this was true only for Windows. On Unix and
Unix-like systems, error output now can be directed to a file or
the console in addition to or instead of the system log as
desired. This is true both for mysqld and
mysqld_safe. Previously,
mysqld_safe ignored its
--syslog
option with a
warning if --log-error
was
also given.
(Bug #55370, Bug #11762739)
If connection IDs went beyond the 32-bit limit and started over at 1, the server now ensures that IDs still in use will not be reissued. (Bug #44167, Bug #11752851)
Internally, spatial data types such as
Geometry
are represented as
BLOB
values, so when invoked with the
--hex-blob
option,
mysqldump now displays spatial values in hex.
(Bug #43544, Bug #11752369)
Scalability for InnoDB
tables was improved by
avoiding THR_LOCK
locks. As a result of this
change, DML statements for InnoDB
tables that
previously waited for a THR_LOCK
lock will
wait for a metadata lock:
Explicitly or implicitly started transactions that update
any table (transactional or nontransactional) will block and
be blocked by LOCK TABLES ... READ
for
that table. This is similar to how LOCK TABLES ...
WRITE
works.
Tables that are implicitly locked by LOCK
TABLES
now will be locked using metadata locks
rather than THR_LOCK
locks (for
InnoDB
tables), and locked using metadata
locks in addition to THR_LOCK
locks (for
all other storage engines). Implicit locks occur for
underlying tables of a locked view, tables used by triggers
for a locked table, or tables used by stored programs called
from such views and triggers.
Multiple-table updates now will block and be blocked by
concurrent LOCK TABLES ... READ
statements on any table in the update, even if the table is
used only for reading.
HANDLER ... READ
for any storage engine
will block and be blocked by a concurrent LOCK
TABLES ... WRITE
, but now using a metadata lock
rather than a THR_LOCK
lock.
The preceding changes are visible several ways. For example,
when a DML statement such as
INSERT INTO t1
in one session is blocked by
LOCK TABLES t1
READ
in another session:
In the Performance Schema, THR_LOCK
acquisitions and waits will be registered in the
metadata_locks
table and for
wait/lock/metadata/sql/mdl
events rather
than registered in the
table_handles
table and for
wait/lock/table/sql/handler
events.
In the process list (SHOW
PROCESSLIST
or
INFORMATION_SCHEMA.PROCESSLIST
),
the state value will be Waiting for table metadata
lock
rather than Waiting for table level
lock
.
The Table_locks_immediate
and Table_locks_waited
status variables will no longer be incremented.
Issues that went away as a result of these locking changes:
For debug builds, concurrent execution of LOCK
TABLES ... READ
and a DML statement affecting the
same InnoDB
table might lead to
Found lock of type 6 that is write and read
locked
warnings in the error log.
Execution of DDL statements under LOCK
TABLES
might have led to deadlock if 1) this
LOCK TABLES
statement, in addition to the
table to be changed by DDL, also had some tables read-locked
or locked implicitly (for example, through triggers) and 2)
there was some concurrent DML which was blocked on a
table-level lock held by LOCK TABLES
and
3) there was a concurrent PREPARE
(or
corresponding connector API call) which prepared a statement
using tables to be affected by the first DDL and some other
table which was affected by another DDL statement which had
to wait for the DML statement.
(Bug #42147, Bug #11751331)
The mysql client now indicates whether
USE
statements produced warnings.
(Bug #29965, Bug #11746951)
In the MySQL client/server protocol, EOF and OK packets serve the same purpose, to mark the end of a query execution result. Due to recent changes in the OK packet (such as session state tracking), and to avoid repeating the changes in the EOF packet, the EOF packet is now deprecated.
The server-side help tables and time zone tables in the
mysql
system database now are
InnoDB
(transactional) tables. Previously,
these were MyISAM
(nontransactional) tables.
The affected tables are:
help_category help_keyword help_relation help_topic time_zone time_zone_leap_second time_zone_name time_zone_transition time_zone_transition_type
If you upgrade to this MySQL release from an earlier version,
you must run mysql_upgrade (and restart the
server) to incorporate these changes into the
mysql
database.
START TRANSACTION
and
COMMIT
statements have been added to the
output from mysql_tzinfo_to_sql used to
populate the time zone tables, to ensure that reload operations
are permanent.
MySQL Server now supports an “offline mode” with these characteristics:
Connected client users who do not have the
SUPER
privilege are
disconnected on the next request, with an appropriate error.
Disconnection includes terminating running statements and
releasing locks. Such clients also cannot initiate new
connections, and receive an appropriate error.
Connected client users who have the
SUPER
privilege are not
disconnected, and can initiate new connections to manage the
server.
Replication slave threads are permitted to keep applying data to the server.
Only users who have the SUPER
privilege can control offline mode. To put a server in offline
mode, change the value of the new
offline_mode
system variable
from OFF
to ON
. To resume
normal operations, change
offline_mode
from
ON
to OFF
. In offline
mode, clients that are refused access receive an
ER_SERVER_OFFLINE_MODE
error.
ALTER TABLE ...
EXCHANGE PARTITION
syntax now includes an optional
{WITH|WITHOUT} VALIDATION
clause. When
WITHOUT VALIDATION
is specified,
ALTER TABLE ...
EXCHANGE PARTITION
does not perform row-by-row
validation when exchanging a populated table with the partition,
permitting database administrators to assume responsibility for
ensuring that rows are within the boundaries of the partition
definition. WITH VALIDATION
is the default
behaviour and need not be specified explicitly. For more
information, see
Exchanging Partitions and Subpartitions with Tables.
mysqlslap now has a
--sql-mode
option that enables
the SQL mode to be set for the client session.
It is now possible to specify the storage engine the server uses
for on-disk internal temporary tables (see
Internal Temporary Table Use in MySQL), by setting the new
internal_tmp_disk_storage_engine
system variable. Permitted values are MYISAM
(the default) and INNODB
.
In consequence of this change, the server is no longer prevented
from using an in-memory temporary table for queries containing a
string column in a GROUP BY
or
DISTINCT
clause larger than 512 bytes for
binary strings or 512 characters for nonbinary strings.
The custom rwlock implementation for Windows was replaced with standard Windows API calls. As a result of this change, Windows binaries require Windows 7 / Windows Server 2008 R2 or newer. In particular, Windows binaries no longer work on Windows Vista or Windows Server 2008 (plain, not R2).
The Boost.Geometry library now is required to build MySQL. Two new CMake options enable control over the library source location, and whether to download it automatically:
-DWITH_BOOST=
specifies the Boost library directory location. It is also
possible to specify the Boost location by setting the
path_name
BOOST_ROOT
or
WITH_BOOST
environment variable.
-DDOWNLOAD_BOOST=
specifies whether to download the Boost source if it is not
present in the specified location. The default is
bool
OFF
.
For example, if you normally build MySQL placing the object
output in the bld
subdirectory of your
MySQL source tree, you can build with Boost like this:
mkdir bld cd bld cmake .. -DDOWNLOAD_BOOST=ON -DWITH_BOOST=$HOME/my_boost
This causes Boost to be downloaded into the
my_boost
directory under your home
directory. If the required Boost version is already there, no
download is done. If the required Boost version changes, the
newer version is downloaded.
If Boost is already installed locally and your compiler finds the Boost header files on its own, it may not be necessary to specify the preceding CMake options. However, if the version of Boost required by MySQL changes and the locally installed version has not been upgraded, you may have build problems. Using the CMake options should give you a successful build.
The deprecated mysqlhotcopy utility has been removed from MySQL distributions. Alternatives include mysqldump and MySQL Enterprise Backup.
The deprecated mysqlbug, mysql_waitpid, and mysql_zap utilities have been removed from MySQL distributions.
The deprecated storage_engine
system variable has been removed. Use
default_storage_engine
instead.
Important Change; Partitioning:
In an ALTER TABLE
statement, the
server accepted REBUILD
with the name of a
subpartition as valid syntax even though the
REBUILD
keyword in this case did nothing. Now
REBUILD
is rejected in such cases, and causes
the statement to fail with an error.
(Bug #19075411, Bug #73130)
References: This issue is a regression of: Bug #14028340, Bug #65184.
Important Change; Replication:
A DROP TABLE
statement may be
divided into multiple statements before it is sent to the binary
log if it contains regular (not temporary) tables and temporary
tables, or if it contains temporary tables using both
transactional and non-transactional storage engines. Now, when
using GTIDs, DROP TABLE
statements affecting
these combinations of tables are no longer allowed unless the
value of the gtid_next
system
variable is AUTOMATIC
. This is because, with
GTIDs enabled on the server, issuing a DROP
TABLE
in the cases just described while having only
one GTID associated with each statement (the SQL thread does
this following
SET
gtid_next='
)
causes problems when there are not enough GTIDs for assignment
to all the resulting statements following the division of the
original uuid
:number
'DROP TABLE
.
A DROP TABLE
statement might be split due to
the behavior of the statement with respect to the current
transaction varying, depending on table characteristics, as
follows:
DROP TABLE
of a regular (not temporary)
table is committed immediately
DROP TABLE
of a temporary table using a
transactional storage engine is committed with the current
transaction (following
COMMIT
)
DROP TABLE
of a temporary table that uses
a nontransactional storage engine is committed immediately
Naming all three of these types of tables in a single
DROP TABLE
statement causes the MySQL server
to divide the original statement into three separate
DROP TABLE
statements in the binary log. If
GTIDs are enabled but the value of gtid_next
is not AUTOMATIC
, issuing a DROP
TABLE
statement that mixes any of the table types
described previously causes the server to have an insufficient
number of GTIDs to write with all of the resulting statements
into the binary log. In addition,
DROP TABLE IF
EXISTS
is always written in the binary log for all
tables specified in the statement, even if some or all of the
tables do not exist.
Because temporary tables are handled differently by
DROP TABLE
depending on whether they use a
transactional or nontransactional storage engine, any tables
named by a DROP TEMPORARY TABLE
statement
that do not exist are assumed to be transactional. This means
that, if a DROP TEMPORARY TABLE
with two
nontransactional temporary tables is issued on the master, it
would writes only one DROP TABLE
statement
naming both tables. If one of the temporary tables no longer
exists on the slave, then, when the SQL thread executes the
statement, it tries to divide it into multiple statements due to
it affecting a nontransactional (but existing) temporary table
and a nonexistent transactional temporary table; this leads to
problems because the SQL thread has only one GTID for the
original DROP TABLE
statement but must write
two DROP TABLE
statements in the binary log.
In addition, when the slave dropped temporary tables after
detecting that the master had restarted, it logged one
DROP TABLE
statement per pseudo-thread and
per database, but combined temporary tables using transactional
and nontransactional storage engines in a single DROP
TABLE
statement.
Now, we throw an error in the client session if
gtid_next
is set to a
uuid
:number
value and a DROP TABLE
statement is issued
mixing any of the table types described previously.
In addition, we now group the nonexistent temporary tables and assume them to be transactional only if at least one transactional temporary table is dropped by the statement. If no transactional temporary tables are dropped, any nonexistent temporary tables are assumed to be nontransactional temporary tables.
The slave now also handles dropping of temporary tables correctly in the event of the restart by the master. (Bug #17620053)
Important Change; Replication:
The maximum length that can be used for the password in a
CHANGE MASTER TO
statement is 32
characters. Previously, when a longer password was employed, it
was accepted, but any excess length was silently truncated by
the server. Following this fix, when the password's length
exceeds 32 characters, CHANGE MASTER TO
fails
with an error.
(Bug #11752299, Bug #43439)
Performance; Replication:
When processing the dump thread, a semisynchronous replication
master checked whether or not the dump thread came from a
semisynchronous slave by checking the value of
rpl_semi_sync_slave_enabled
,
but did so for every operation performed on this thread, which
had significant negative impact on performance. Now this check
is made only once, when the dump thread is started, which should
noticeably improve the performance of semisynchronous
replication in most cases.
(Bug #17932935)
InnoDB; Partitioning:
Large numbers of partitioned InnoDB
tables could consume much more memory when used in MySQL 5.6 or
5.7 than the memory used by the same tables used in previous
releases of the MySQL Server.
(Bug #17780517, Bug #70641)
References: This issue is a regression of: Bug #11764622, Bug #57480.
InnoDB; Linux:
The TTASFutexMutex
, the mutex implementation
that uses the Linux futex, failed to request
m_lock_word
alignment.
(Bug #19525395, Bug #73760)
InnoDB:
If a crash occurs after a drop index action during a
TRUNCATE TABLE
operation, the
root page could be left in a free state. On crash recovery, an
LSN check failed to check free
pages when attempting to pin the root page, resulting in an
assertion.
(Bug #19520482)
InnoDB:
Replaced a goto
statement with an
if
statement in the
fil_mutex_enter_and_prepare_for_io
function
in fil0fil.cc
.
(Bug #19488149)
InnoDB:
An INSERT
operation on a table
with spatial data columns raised an assertion.
(Bug #19474851)
InnoDB:
Removed unused code related to binary log information stored in
the InnoDB
trx_sys
page.
(Bug #19471743)
InnoDB:
An ALTER TABLE ...
ADD FOREIGN KEY
operation could cause a serious error.
(Bug #19471516, Bug #73650)
InnoDB:
Reduced mem_heap_zalloc
calls in
upd_create
. Only a single call is necessary
to allocate memory for upd_t
.
(Bug #19297656, Bug #73272)
InnoDB:
In debug builds, an INSERT
operation affecting compressed tables would raise a sync-related
assertion.
(Bug #19295893)
InnoDB:
An ALTER TABLE
operation raised
an fk_tables.empty()
assertion. After calling
dict_load_foreigns()
, all associated tables
that are linked by a foreign key should be loaded to ensure that
foreign keys are cached.
(Bug #19267051)
References: This issue is a regression of: Bug #16244691.
InnoDB: A transaction returned from the transaction pool was not in a clean state. (Bug #19244969)
InnoDB:
An MLOG_CHECKPOINT
marker was incorrectly
omitted when performing a log checkpoint.
(Bug #19233510, Bug #73304)
InnoDB:
On crash recovery, InnoDB
would call
exit()
when encountering a corruption or
inconsistency. Some of the exit()
calls have
been removed to allow InnoDB
to shut down
properly.
(Bug #19229231, Bug #73300)
InnoDB:
When multiple
daemon_memcached_option
options
are defined, the
INFORMATION_SCHEMA.GLOBAL_VARIABLES
table and SHOW VARIABLES
statement should only display the first
daemon_memcached_option
option
that is defined in the command line string or in the MySQL
configuration file.
(Bug #19204759, Bug #73287)
InnoDB:
Running SHOW ENGINE INNODB STATUS
repeatedly
under performance testing conditions could result in a serious
error.
(Bug #19196052)
InnoDB:
Removed unused one_flush
variable from
storage/innobase/include/log0log.h
.
(Bug #19192364, Bug #73269)
InnoDB:
Retrieval of multiple values with a single
get
command would return incorrect results
instead of an error message. The InnoDB
memcached plugin does not currently support
retrieval of multiple values with a single
get
command.
(Bug #19172212, Bug #72453)
InnoDB: Attempting to perform operations on a timed out key would cause the memcached daemon to crash and restart. (Bug #19172013, Bug #72586)
InnoDB:
An ALTER TABLE
operation that
does not perform a sort on the clustered index could result in a
duplicate record.
(Bug #19163915)
References: See also: Bug #17657223.
InnoDB: Improved error handling, diagnostics, and test coverage related to crash recovery error handling. (Bug #19145637, Bug #73179)
InnoDB:
Improved error handling for calls to
handler::records()
.
(Bug #19142753)
References: This issue is a regression of: Bug #16802288.
InnoDB:
With a transaction isolation level less than or equal to
READ COMMITTED
, gap locks were not taken when
scanning a unique secondary index to check for duplicates. As a
result, duplicate check logic failed allowing duplicate key
values in the unique secondary index.
(Bug #19140907)
References: This issue is a regression of: Bug #16133801.
InnoDB:
A race condition that occurred when dynamically disabling
innodb_adaptive_hash_index
caused the purge thread to assert.
(Bug #19069698)
InnoDB:
The INNODB_PAGE_ATOMIC_REF_COUNT
CMake option is removed in MySQL 5.7.5. This
option was enabled by default but could be disabled for systems
that do not support atomic operations. As of MySQL 5.7.5,
support for atomic operations is required to build MySQL, making
the INNODB_PAGE_ATOMIC_REF_COUNT
option obsolete.
(Bug #19061440)
InnoDB:
In debug builds, an invalid rw_latch ==
RW_NO_LATCH
assertion would cause the server to halt.
(Bug #18977128)
InnoDB: Added debug assertions to the adaptive hash index code to check that the tablespace ID in buffer blocks match the index space. (Bug #18965518, Bug #72986)
InnoDB: During recovery, a segmentation fault would occur when marking a table as corrupt. (Bug #18942294)
References: This issue is a regression of: Bug #11830883.
InnoDB:
A code comment for the os_event_is_set
function in storage/innobase/os/os0event.cc
was incorrect.
(Bug #18940008, Bug #72919)
InnoDB:
A latching order violation would occur while inserting
BLOB
data.
(Bug #18883885)
InnoDB:
For PowerPC, InnoDB
now uses special PowerPC
instructions for setting priority of hardware threads in
InnoDB
mutex spin loops. Thanks to Stewart
Smith for the contribution.
(Bug #18842925, Bug #72754)
InnoDB:
The innodb_memcached_config.sql
configuration
script failed after running the
mysql_secure_installation
script, which
removes the MySQL test
database. The
innodb_memcached_config.sql
script now
creates the test
database if it does not
exist.
(Bug #18816381, Bug #72678)
InnoDB:
Removed unused function definitions and declarations from the
InnoDB
memcached API.
(Bug #18815992, Bug #72723)
InnoDB:
CACHE_LINE_SIZE
for PowerPC was changed from
64 bytes to 128 bytes.
(Bug #18814859, Bug #72718)
InnoDB: Opening a parent table that has thousands of child tables could result in a long semaphore wait condition. (Bug #18806829)
InnoDB:
trx_cleanup_at_db_startup
failed to reset
trx->rsegs->m-redo
content in debug
code.
(Bug #18795594)
InnoDB:
On mysqld start, specifying multiple data
files using the
innodb_data_file_path
option
would return a Space id in fsp header
error after data is written to the second file.
(Bug #18767811)
InnoDB:
When storing BLOB
data,
InnoDB
failed to reserve the required
tablespace pages prior to allocating the pages, which raised an
assertion on INSERT
.
(Bug #18756233)
InnoDB:
A failed in-place ALTER TABLE
operation would leave behind nonunique temporary file names in
the data dictionary preventing future ALTER
TABLE
operations on the same table due to temporary
file name conflicts. To avoid this problem, temporary file names
are made unique by appending a static global number that is
initialized to a random distributed 32-bit number using
ut_time()
and ut_crc32()
.
The number is then incremented atomically for each assigned
temporary file name. Previously, temporary files were named
using the format #sql-ibtid
, where
tid
is the table ID. Temporary files are now
named using the format #sql-ibtid-inc
,
where tid
is the table ID and
inc
is the incremented number.
(Bug #18734396, Bug #72594)
InnoDB:
A regression introduced by the fix for Bug #11758237 resulted in
a cursor->index->name ==
TEMP_INDEX_PREFIX
assertion.
(Bug #18723872)
References: This issue is a regression of: Bug #11758237.
InnoDB: For single item full-text searches, deleted documents were included in inverse document frequency (IDF) calculations. (Bug #18711306, Bug #72548)
InnoDB:
The page_create
function has been optimized
to use simpler functions to initialize pages.
(Bug #18704384)
InnoDB:
A DELETE
operation on a table with full-text
search indexes raised an assertion.
(Bug #18683832)
References: See also: Bug #14639605.
InnoDB:
To-be-imported tablespace files
(FIL_TYPE_IMPORT
) were not flushed after
being converted to normal tablespace files
(FIL_TYPE_TABLESPACE
), resulting in too many
open files.
(Bug #18663997)
References: This issue is a regression of: Bug #18236692.
InnoDB:
When InnoDB
is built as a shared library,
attempting to load the InnoDB
full-text
search (FTS) INFORMATION_SCHEMA
plugin would
fail with a Can't open shared library
'ha_innodb.so' error.
(Bug #18655281, Bug #70178)
InnoDB:
When calling the memcached
flush_all
command, InnoDB
attempts to initialize a connection and a transaction. If the
transaction is in TRX_STATE_NOT_STARTED
state, InnoDB
failed to set
CONN_DATA->CRSR_TRX
to NULL, resulting in
a serious error.
(Bug #18652854)
InnoDB:
An INSERT
operation on a table
with BLOB
columns raised an
assertion.
(Bug #18646430)
References: This issue is a regression of: Bug #16963396.
InnoDB:
An INSERT
operation on a table with
GEOMETRY
columns raised an assertion in
rtr_page_split_and_insert()
.
(Bug #18644435)
InnoDB:
The temporary tablespace file (ibtmp1
) was
held open by the page_cleaner
thread and
could not be removed on startup, resulting in a hang.
(Bug #18642372)
InnoDB:
A regression introduced in MySQL 5.6.5 would cause full-text
search index tables to be created in the system tablespace
(space 0) even though
innodb_file_per_table
was
enabled.
(Bug #18635485)
InnoDB:
After upgrading from 5.6.10 to MySQL versions up to and
including MySQL 5.6.18, InnoDB
would attempt
to rename obsolete full-text search auxiliary tables on server
startup, resulting in an assertion failure.
(Bug #18634201, Bug #72079)
InnoDB: In rare cases, the purge process would attempt to delete a secondary index record that was not marked for deletion, resulting in an inconsistent secondary index. (Bug #18631496)
InnoDB:
After running OPTIMIZE TABLE
on
an InnoDB
table with a spatial index, running
a SELECT
statement that uses the
spatial index could result in a crash.
(Bug #18619945, Bug #72361)
References: This issue is a regression of: Bug #13975225.
InnoDB:
On startup, with
innodb_file_per_table=ON
, the
page cleaner thread would raise a
srv_get_active_thread_type() == SRV_NONE
debug assertion when encountering an active master thread.
(Bug #18598813)
InnoDB:
InnoDB
would try to merge a b-tree change
buffer for a dedicated undo tablespace.
(Bug #18593561)
InnoDB:
Included unistd.h
in
innodb.cmake
to enable futexes in debug
builds.
(Bug #18522549, Bug #72225)
InnoDB:
TRUNCATE TABLE
would write
page-level redo logs during the DROP
TABLE
step of a TRUNCATE
TABLE
operation.
(Bug #18511398)
InnoDB:
A COMMIT
operation related to full-text
search resulted in a segmentation fault.
(Bug #18503734)
InnoDB:
srv_active_wake_master_thread()
was called
directly in innobase_commit
and
innobase_prepare
, waking up the master thread
and incrementing srv_activity_count
.
srv_active_wake_master_thread()
should only
be called after committing write transactions, not after
read-only transactions or rollbacks. This patch also replaces
some calls to srv_active_wake_master_thread()
with calls to ib_wake_master_thread()
.
(Bug #18477009, Bug #72137)
InnoDB:
A DB_LOCK_WAIT
during a foreign key check
caused redundant delete marking, resulting in a failing
assertion.
(Bug #18451287)
InnoDB:
With UNIV_SYNC_DEBUG
enabled, a late call to
sync_check_enable()
would result in an
m_enabled
assertion failure.
(Bug #18433658)
InnoDB:
InnoDB
would write to the redo log for an
IMPORT TABLESPACE
operation before the
tablespace import was complete.
(Bug #18424134)
InnoDB:
The InnoDB
memcached
plugin would call plugin_del
without
acquiring the lock_plugin
mutex. This bug fix
also addresses a race condition in
ib_cursor_delete_row
.
(Bug #18409840)
InnoDB:
The os_event_wait_time_low
function would
sometimes return OS_SYNC_TIME_EXCEEDED
before
the sync time has elapsed.
(Bug #18386498)
InnoDB:
With persistent statistics enabled, SHOW
TABLE STATUS
output and the
TABLE_ROWS
column of
INFORMATION_SCHEMA.TABLES
could report an
incorrect number of table rows for tables with externally stored
pages.
(Bug #18384390)
InnoDB:
Running a SELECT
on a partitioned table
caused a memory access violation in memcpy()
.
(Bug #18383840)
References: See also: Bug #18167648.
InnoDB: A regression introduced by the fix for Bug#18069105 could result in a table corruption and failing assertions. (Bug #18368345)
References: This issue is a regression of: Bug #18069105.
InnoDB:
The data file was not opened prior to calling
fil_fusionio_enable_atomic_write()
, resulting
in an assertion failure.
(Bug #18368241)
InnoDB: The fix for Bug#17699331 caused a high rate of read/write lock creation and destruction which resulted in a performance regression. (Bug #18345645, Bug #71708)
References: This issue is a regression of: Bug #17699331.
InnoDB: Code quality improvements for the redo log subsystem. (Bug #18345004)
InnoDB:
Added the C++ ostream
mechanism for error
logging.
(Bug #18320915)
InnoDB:
Removed the recv_max_parsed_page_no
code
variable, which was only used in a diagnostic error message.
(Bug #18312967)
InnoDB:
buf_pool->flush_rbt
, which is only
intended to be used for recovery, would be allocated for
database creation and never freed.
(Bug #18253089)
InnoDB:
Calls to sched_getcpu
would cause page
faults.
(Bug #18225489)
InnoDB:
ib_heap_resize
failed to verify that
new_size
is greater than or equal to
old_size
before calling
memcpy
.
(Bug #18178915)
InnoDB:
After crash recovery and with UNIV_DEBUG
enabled, purge failed with a buf_pool_from_bpage(bpage)
== buf_pool
assertion failure.
(Bug #18154145)
InnoDB:
Assertion code in buf_page_release_latch()
in
buf0buf.ic
was too restrictive.
(Bug #17869571)
InnoDB:
For each insert, memset
would be called three
times to allocate memory for system fields. To reduce CPU usage,
the three memset
calls are now combined into
a single call.
(Bug #17858679, Bug #71014)
InnoDB:
The fix for Bug#16418661 added superfluous
buf_flush_list()
logic to
InnoDB
startup code.
(Bug #17798076, Bug #70899)
References: This issue is a regression of: Bug #16418661.
InnoDB:
A problem renaming temporary tables during an ALTER
TABLE
operation would raise an assertion and print a
warning to the error log. Temporary table names were not
sufficiently unique.
(Bug #17713871)
InnoDB:
In-place ALTER TABLE
operations
requiring a table rebuild would sort the clustered index even
though the primary key order remained unchanged. This behavior
caused unnecessary temporary table usage and I/O.
(Bug #17657223)
InnoDB:
Under certain circumstances, adaptive hash index latches
(btr_search_latch
) were persistent. With
atomics-based rw-locks (read-write locks), persistent adaptive
hash index latches are unnecessary and may block other adaptive
hash index updates.
(Bug #17554489, Bug #70216)
InnoDB:
A race condition in fts_get_next_doc_id
resulted in Duplicate FTS_DOC_ID and
Cannot find index FTS_DOC_ID_INDEX in InnoDB index
translation table errors.
(Bug #17447086, Bug #70311)
References: See also: Bug #16469399.
InnoDB:
Enabling the InnoDB
Table Monitor would
result in a ib_table->stat_initialized
assertion failure.
(Bug #17039528, Bug #69641)
InnoDB:
Redo log writes for large, externally stored
BLOB
fields could overwrite the most recent
checkpoint. The 5.6.20 patch limits the size of redo log
BLOB
writes to 10% of the redo
log file size. The 5.7.5 patch addresses the bug without
imposing a limitation. For MySQL 5.5, the bug remains a known
limitation.
(Bug #16963396, Bug #19030353, Bug #69477)
InnoDB:
The error log message that is printed on
CREATE TABLE
when the number of
BLOB
or
TEXT
fields exceed the row size
limit did not provide sufficient information. The error message
now provides the maximum row size, current row size, and the
field that causes the maximum row size to be exceeded.
(Bug #16874873, Bug #69336)
InnoDB:
An in-place ALTER TABLE
operation on a table
with a broken foreign key constraint could raise an assertion.
(Bug #16869435)
InnoDB:
The lock_number_of_rows_locked
function used
a bit vector to track the number of record locks held by a
transaction. To optimize reporting, the bit vector was replaced
by a simple counter.
(Bug #16479309, Bug #68647)
InnoDB:
Inserting a record into an InnoDB
table with
a key that falls between the maximum key of a full page and the
minimum key of the “next” page could result in
unnecessary page splits and under-filled pages. If the insert
point is at the end of a page, InnoDB
now
attempts to insert to the next page before splitting the page.
(Bug #15923864, Bug #67718)
InnoDB:
With
innodb_max_dirty_pages_pct=0
buffer pool flushing would not be initiated until the percentage
of dirty pages reached at least 1%, which would leave up to 1%
of dirty pages unflushed.
(Bug #13029450, Bug #62534)
InnoDB: Due to differences in memory ordering on different processor types, some mutex and read-write lock flags were not read consistently. (Bug #11755438, Bug #47213)
InnoDB:
Debug assertion code in file row0ins.cc
did
not account for rw-lock shared-exclusive (sx-lock) mode,
resulting in an assertion failure.
(Bug #73534, Bug #19420253)
InnoDB:
With foreign_key_checks=0
,
InnoDB
permitted an index required by a
foreign key constraint to be dropped, placing the table into an
inconsistent and causing the foreign key check that occurs at
table load to fail. InnoDB
now prevents
dropping an index required by a foreign key constraint, even
with foreign_key_checks=0
. The
foreign key constraint must be removed before dropping the
foreign key index.
(Bug #70260, Bug #17449901)
Partitioning:
When the
index_merge_intersection
flag
(enabled by default) or the
index_merge_union
flag was
enabled by the setting of the
optimizer_switch
system
variable, queries returned incorrect results when executed
against partitoned tables that used the
MyISAM
storage engine, as well as
partitioned InnoDB
tables that
lacked a primary key.
(Bug #18167648)
References: See also: Bug #16862316, Bug #17588348, Bug #17648468.
Partitioning:
Selecting from a table having multiple columns in its primary
key and partitioned by LIST
COLUMNS(
, where
R
)R
was the last (rightmost) column
listed in the primary key definition, returned an incorrect
result.
(Bug #17909699, Bug #71095)
Replication:
Misleading or confusing error messages have been revised, which
were produced in the following 2 cases when using
mysqlbinlog with the
--raw
option:
When this option was used together with
--include-gtids
.
When this option was used together with
--exclude-gtids
and
--read-from-remote-master=BINLOG-DUMP-NON-GTIDS
.
(Bug #19459836, Bug #73625)
Replication: After the fix for Bug #16861624, killing a multithreaded slave worker which was waiting for a commit lock caused a debug assertion to fail. This fix ensures that such a situation can not occur. (Bug #19311260)
Replication:
Temporary errors related to a slave worker thread which was
retrying a transaction were visible in SHOW
SLAVE STATUS
. This fix ensures that slave worker
threads do not store temporary errors in the slave status.
(Bug #19282301)
Replication:
A corrupted header length in
FORMAT_DESCRIPTION_LOG_EVENT
could cause the
server to stop unexpectedly. This was due to
FORMAT_DESCRIPTION_LOG_EVENT
being considered
invalid if the header length was too short.
(Bug #19145712)
Replication: Removed an unnecessary write lock that was taken by an internal function while adding a GTID to a GTID set, which should improve the performance of the function and the code dependent on it during such operations. (Bug #18963555, Bug #72977)
Replication:
Semisynchronous replication did not work as expected when the
rpl_semi_sync_master_wait_no_slave
and
rpl_semi_sync_master_wait_for_slave_count
variables were set. The values of the variables were changed,
but the related internal status was not updated during
initialization.
(Bug #18835117, Bug #18466390)
Replication:
RESET SLAVE
ALL
did not clear
IGNORE_SERVER_IDS
, although this statement
should clear any values that are set by
CHANGE MASTER TO
. Now
RESET SLAVE ALL
always empties the list of
server IDs to ignore, whenever it is executed.
(Bug #18816897)
Replication: The same internal function had effects which caused three similar problems when resetting or starting slaves. These three issues are listed here:
RESET SLAVE
automatically set
the heartbeat period
(Slave_heartbeat_period
)
to its default value.
RESET SLAVE
automatically set
SSL_VERIFY_SERVER_CERT
to the default.
When a server was not configured as a slave (that is, when
no CHANGE MASTER TO
statement
had yet been executed), the subsequent failure of
START SLAVE
was expected but
had the unintended side effect of resetting the heartbeat
period to the default.
The function has been rewritten such that code affecting
heartbeat or SSL certificate usage has been eliminated or moved
to a more appropriate location, eleminating the side effects
formerly seen with RESET SLAVE
or a failed
START SLAVE
.
As part of this fix, in order to be able to keep heartbeats
enabled by default when changing the master, if host and port
are given but the heartbeat period is not specified in a
CHANGE MASTER TO
statement, we force it to
the default value.
(Bug #18791604, Bug #18778485, Bug #18777899)
Replication:
mysqlbinlog
--raw
did not check for
errors caused by failed writes, which could result in silent
corruption of binary logs. Now in such cases it stops with an
error.
(Bug #18742916, Bug #72597)
Replication:
When committing a transaction, a flag is now used to check
whether a thread has been created, rather than checking the
thread itself, which uses more resources, particularly when
running the server with
master_info_repository=TABLE
.
(Bug #18684222)
References: See also: Bug #17967378.
Replication: When a slave worker thread tried to execute a statement that was too large, the resulting error caused a crash. Now in such cases, the error is truncated to fit the size of the buffer. (Bug #18563480)
Replication:
Log rotation events could cause
group_relay_log_pos
to be moved forward
incorrectly within a group. This meant that, when the
transaction was retried, or if the SQL thread was stopped in the
middle of a transaction following one or more log rotations
(such that the transaction or group spanned multiple relay log
files), part or all of the group was silently skipped.
This issue has been addressed by correcting a problem in the logic used to avoid touching the coordinates of the SQL thread when updating the log position as part of a relay log rotation whereby it was possible to update the SQL thread's coordinates when not using a multithreaded slave, even in the middle of a group. (Bug #18482854)
Replication:
When using GTIDs with MASTER_AUTO_POSITION
enabled, if an I/O thread was restarted it failed with an
ER_GTID_NEXT_TYPE_UNDEFINED_GROUP
error due to a partial transaction not being correctly rolled
back before resuming the I/O thread. This fix ensures that the
partial transaction is correctly rolled back.
(Bug #18472603)
Replication:
When using row-based replication, updating or deleting a row on
the master that did not exist on the slave led to failure of the
slave when it tried to process the change. This problem occurred
with InnoDB
tables lacking a
primary key.
(Bug #18432495, Bug #72085)
Replication:
A multithreaded slave now checks that a free worker is available
to dispatch the next event. In previous versions, a
multithreaded slave crashes with a worker error if the thread
coordinator can not find a free worker. The crash was caused
when the coordinator did not return a free worker, for example
if the coordinator was aborted at the same time using
STOP SLAVE
.
(Bug #18363515)
Replication:
When replicating from a MySQL 5.5 or earlier master to a MySQL
5.6 or later slave, the SOURCE_UUID
column of
the slave's
performance_schema.replication_connection_status
table contained random data. Now in such cases,
SOURCE_UUID
is left blank.
(Bug #18338203)
Replication: During relay log initialization, the thread context was used as a flag for the reconstruction of the retrieved GTID set, an operation that does not depend on this parameter. This could be problematic if relay log initialization was called in another context other than the legacy replication scenario; if the invocation was made in a context where the thread context was always present, this prevented the set's reconstruction. The opposite could also happen when the thread context was not present, which cause the initialization to be performed twice.
To avoid such issues, the thread context flag is replaced with a new flag that allows the reconstruction in all contexts but prevents multiple invocations. (Bug #18337036)
Replication:
When mysqlbinlog processed multiple binary
log files into a single output file, this file was not in a
useful state for point-in-time recovery, when it failed with the
error, When @@SESSION.GTID_NEXT is set to a GTID, you
must explicitly set it to a different value after a COMMIT or
ROLLBACK. Please check GTID_NEXT variable manual page for
detailed explanation. Current @@SESSION.GTID_NEXT is
'xyz
'. When
mysqlbinlog processes a binary log containing
GTIDs, it outputs
SET
gtid_next
statements, but
gtid_next
is set to undefined whenever a
commit occurs; this left gtid_next
undefined
when the server had finished processing the output from
mysqlbinlog. When the next binary log file
started with one or more anonymous statements or transactions,
the combination of gtid_next being left undefined at the end of
the first binary log and the second binary log containing
anonymous transactions to the error described previously (Error
1837, ER_GTID_NEXT_TYPE_UNDEFINED_GROUP).
To fix this issue, now, whenever mysqlbinlog
encounters this situation, it inserts SET gtid_next =
AUTOMATIC
if required to avoid leaving the previous
binary log with gtid_next
undefined.
In addition, as a result of this fix, mysqlbinlog no longer outputs session variable information for every binary log; now, this value is printed only once unless it changes. (Bug #18258933, Bug #71695)
Replication:
Quotation marks were not always handled correctly by
LOAD DATA
when written into the
binary log.
(Bug #18207212, Bug #71603)
Replication:
Changing master_info_repository
between TABLE
and FILE
could produce duplicate values in the
Replicate_Ignore_Server_Ids
column of the
output from SHOW SLAVE STATUS
and
the Ignored_server_ids
column of the
mysql.slave_master_info
table. This could
arise because the list of IDs stored internally by the server
was not always sorted before checking for duplicates when
inserting new values into the list. Now the list of server IDs
to be ignored is always sorted, prior to performing this check.
(Bug #18192817, Bug #18593479, Bug #18920203)
Replication:
In certain cases, the server mishandled triggers and stored
procedures that tried to modify other tables when called by
CREATE
TABLE ... SELECT
. This is now handled correctly as an
error.
(Bug #18137535)
Replication:
The REPLICATE_WILD_DO_TABLE
and
REPLICATE_WILD_IGNORE_TABLE
options for
CHANGE REPLICATION FILTER
could
be employed with values which contained no period
(.
) character, even though values for these
options must be in the format
..
(Bug #18095449)db_name
.tbl_name
Replication:
When used on a table employing a transactional storage engine, a
failed TRUNCATE TABLE
was still
written to the binary log and thus replayed on the slave. This
could lead to inconsistency when the master retained data that
was removed on the slave.
Now in such cases TRUNCATE TABLE
is logged
only when it executes successfully.
(Bug #17942050, Bug #71070)
Replication:
Beginning in MySQL 5.6.20, when a user specified
AUTO_INCREMENT
value falls outside of the
range between the current AUTO_INCREMENT
value and the sum of the current and number of rows affected
values it is replicated correctly. In previous versions, an
error was generated by the slave even if the user specified
AUTO_INCREMENT
value fell outside of the
range.
(Bug #17588419, Bug #70583)
Replication: When the I/O thread reconnected to a master using GTIDs and multithreaded slaves while in the middle of a transaction, it failed to abort the transaction, leaving a partial transaction in the relay log, and then retrieving the same transaction again. This occurred when performing a rotation of the relay log. Now when reconnecting, the server checks before rotating the log in such cases, and waits first for any ongoing transaction to complete. (Bug #17326020)
Replication: On Windows, mysqldump failed if the error log file was deleted (missing) from the active MySQL server. (Bug #17076131)
Replication:
When the binary log was rotated due to receipt of a
SIGHUP
signal, the new binary log did not
contain the Previous_gtid_event
required for
subsequent processing of that binary log's GTID events. Now when
SIGHUP
is received, steps are taken to insure
that the server writes the necessary
Previous_gtid_event
to the new log before
writing any GTID events to the new log.
(Bug #17026898)
Replication:
The CLIENT_REMEMBER_OPTIONS
flag for
compressed slave connections is no longer reset and all options
are retained. This restores functionality of all options to
compressed slave connections.
(Bug #72901, Bug #18923691, Bug #73324, Bug #19244772)
Replication:
When using row-based replication, setting a slave's
slave_rows_search_algorithms
variable to HASH_SCAN
caused an
ER_KEY_NOT_FOUND
error even
though that record existed in the storage layer. This fix
ensures that the unique key for each record is correctly
maintained and such a situation does not occur.
(Bug #72788, Bug #18860225)
Replication: When using row-based replication, running a long transaction involving a large number of events could trigger an Out of Memory (OOM) error if the slave's table structure was not compatible with the master's table structure. Such an incompatible situation could occur if the table on the slave had been manually changed, or when replicating between different MySQL versions that have different data types. This OOM error was caused because the virtual temporary tables created for the row conversion were not being freed until the end of the transaction, which was a problem when replicating large numbers of events.
Starting with this version, such virtual tables are correctly freed during the conversion process. (Bug #72610, Bug #18770469)
References: See also: Bug #19692387.
Replication: The error messages generated when a duplicate server UUID causes issues during replication have been improved. The slave error now identifies the duplicate server UUID and the master error identifies the zombie thread that has been killed. (Bug #72578, Bug #18731211)
Replication:
When an event group was spanned across multiple relay log files,
a slave could incorrectly identify GTID-header group boundaries.
This meant that when a transaction was retried, or if the SQL
thread was stopped in the middle of a transaction after some
rotates, the Gtid_log_event
was being
silently skipped on the slave, and the transaction was logged
with the slave's GTID. This problem also impacted on using
START SLAVE UNTIL MASTER_LOG_POS =
with GTIDs
enabled. If log_pos
;log_pos
was in the middle
of a transaction, the Gtid_log_event
was not
correctly detected as the beginning of the transaction and
replication stopped before this event. With this fix, threads
correctly detect that they are part of a group, and this is used
to check if a Gtid_log_event
is part of a
transaction.
(Bug #72313, Bug #18652178, Bug #18306199)
Replication:
When gtid_mode=ON
, and a
transaction is filtered out on the slave, the GTID of the
transaction is still logged on the slave as an
“empty” transaction (consisting of a GTID followed
immediately by
BEGIN
and then
COMMIT
). This is necessary to
prevent the transaction from being retransmitted the next time
the slave reconnects or is involved in a failover. The current
fix addresses two issues relating to such “empty”
transactions:
No empty transaction was generated for
CREATE
TEMPORARY TABLE
or
DROP TEMPORARY
TABLE
statements.
If the slave used a database filter
(--replicate-do-db
or
--replicate-ignore-db
option), no empty transaction was generated.
(Bug #71376, Bug #18095502, Bug #18145032)
Replication:
Client applications should be able to set the
BINLOG_DUMP_NON_BLOCK
flag in the initial
handshake packet (COM_BINLOG_DUMP
). Clients
connecting to a server issuing a
COM_BINLOG_DUMP
with the flag unset do not
get an EOF when the server has sent the last event in the binary
log, which causes the connection to block. This flag, which was
removed in error in MySQL 5.6.5, is now restored in the current
release.
As part of this fix, a new
--connection-server-id
option is added to mysqlbinlog. This option
can be used by the client to test a MySQL server for the
presence of this issue.
(Bug #71178, Bug #18000079)
Replication:
On a master that is using semisynchronous replication, where
rpl_semi_sync_master_wait_no_slave
is enabled and
rpl_semi_sync_master_timeout
is
set to long timeout, killing the I/O thread could cause the
server to hang on shutdown. This fix ensures that if the dump
thread finds that there no semisynchronous slaves connected to
the master, the setting of
rpl_semi_sync_master_wait_no_slave
is ignored
and the shutdown proceeds correctly.
(Bug #71047, Bug #17879675)
Replication: Uninstalling and reinstalling semisynchronous replication plugins while semisynchronous replication was active caused replication failures. The plugins now check whether they can be uninstalled and produce an error if semisynchronous replication is active. To uninstall the master-side plugin, there must be no semisynchronous slaves. To uninstall the slave-side plugin, there must be no semisynchronous I/O threads running. (Bug #70391, Bug #17638477)
Replication: When using semisynchronous replication, if the binary log position was changed to a future position on a slave then an assertion error was generated on the master. This fix ensures that in such a situation the future position is correctly acknowledged and an error is instead generated on the slave. (Bug #70327, Bug #17453826)
Replication:
Replication of tables that contained temporal type fields (such
as TIMESTAMP
, DATETIME
,
and TIME
) from different MySQL versions
failed due to incompatible TIMESTAMP
types.
The fractional TIMESTAMP
format added in
MySQL 5.6.4 was not being correctly converted. You can now
replicate a TIMESTAMP
in either format
correctly according to the
slave_type_conversions
variable.
(Bug #70124, Bug #17532932)
Replication: A group of threads involved in acquiring locks could deadlock when the following events occurred:
Dump thread reconnects from slave; on master, a new dump
thread tries to kill zombie dump threads; having acquired
the thread's LOCK_thd_data
, it is about
to acquire LOCK_log
.
Application thread executing show binary logs, having
acquired LOCK_log
and about to acquire
LOCK_index
.
Application thread executing PURGE BINARY
LOGS
; having acquired
LOCK_index
, it is about to acquire
LOCK_thread_count
.
Application thread executing SHOW
PROCESSLIST
(or SELECT * FROM
INFORMATION_SCHEMA.PROCESSLIST
), having acquired
LOCK_thread_count
and about to acquire
the zombie dump thread's LOCK_thd_data
.
This leads to the 4 threads deadlocking in the same order which the threads have been listed here.
This problem arises because there are ordering rules for
LOCK_log
and LOCK_index
,
as well as rules for ordering
LOCK_thread_count
and
LOCK_thd_data
, but there are no rules for
ordering across these two sets of locks. This was because the
internal mysqld_list_processes()
function
invoked by SHOW PROCESSLIST
acquired
LOCK_thread_count
for the complete lifetime
of the function as well as acquiring and releasing each thread's
LOCK_thd_data
. Now this function takes a copy
of the threads from the global thread list and performs its
traversal on these, and only after releasing
LOCK_thread_count
. During this traversal,
removal from the global thread list is blocked using
LOCK_thd_remove
such that the copies that
would otherwise be destroyed by the removal remain valid during
traversal. The locking order following this fix is shown here:
LOCK_thd_remove -> LOCK_thd_data -> LOCK_log -> LOCK_index -> LOCK_thread_count
(Bug #69954, Bug #17283409)
References: See also: Bug #73475, Bug #19364731, Bug #19365180.
Replication: When an SQL thread which was waiting for a commit lock was killed and restarted it caused a transaction to be skipped on slave. This fix ensures that thread positions are correctly persisted and transactions resume at the correct position. (Bug #69873, Bug #17450876)
Microsoft Windows:
To help with crash analysis on Windows, more information has
been added to the core file that is written on
mysqld abort when the
core-file
option is enabled.
(Bug #14041454)
With DTrace support enabled, certain other compilation options could cause the build to fail. (Bug #19506247)
yaSSL client code did not validate the encryption size or session ID length, which could cause the client to exit. (Bug #19463277, Bug #19463565)
Before fsync operations, the server reports a wait, but it reported a table-lock wait rather than a sync wait. This is a minor problem, possibly resulting in come incorrect thread pool plugin statistics. (Bug #19428231)
The optimizer could raise an assertion due to incorrectly handling the table map while sorting an internal temporary table. (Bug #19416826)
yaSSL could fail preauthorization if the client supplied inaccurate buffer lengths. (Bug #19370676, Bug #19355577)
Using Multi-Range Read (MRR) for table access could leak Performance Schema instrumented table handles. (Bug #19301539)
For InnoDB
full-text searches, invalid
multibyte gb10830
characters could cause a
server exit.
(Bug #19233075)
Competition between threads could lead to timeout failure trying to rotate the audit log file. (Bug #19184973)
On Windows, sql_yacc.cc
and
sql_yacc.h
were generated twice during the
build process. This can lead to compilation failure if parallel
processes are permitted.
(Bug #19060850, Bug #27470071, Bug #89482)
Repetitive functions called as arguments to
ExtractValue()
were not always
handled correctly.
(Bug #19051306)
For large sets, EXPORT_SET()
could produce undefined results or a cause a server exit.
(Bug #19048609)
Invalid utf16
data could cause the server to
become unresponsive.
(Bug #18937504)
LPAD()
and RPAD()
could
cause a server exit if the pad string argument was not well
formed.
(Bug #18935421)
The optimizer could create a zero-length column for a temporary table, causing a server exit. (Bug #18928848)
In debug builds, certain range queries could cause an assertion failure. (Bug #18921626)
Improper copying of query strings between the
Prepared_statement
and THD
data structures could result in a server exit.
(Bug #18920075)
Performance Schema memory instrumentation did not honor the
ENABLED
flag in the
setup_instruments
table or the
consumers in the setup_consumers
table. This has been corrected, with the result that unnecessary
statistics are not collected and overhead is reduced.
(Bug #18900309)
When a SELECT
included a derived table in a
join in its FROM
list and the
SELECT
list included
COUNT(DISTINCT)
, the
COUNT()
returned 1 even if the underlying
result set was empty.
(Bug #18853696)
References: This issue is a regression of: Bug #11760197.
Conversion failure of “zero” dates in strict SQL mode could cause a server exit. (Bug #18840123)
Modulo operations on DECIMAL
values in some cases could overflow and cause a server exit.
(Bug #18839617)
Enabling optimizer trace could cause a server exit for queries
with a subquery in a HAVING
clause.
(Bug #18791851)
SHA and MD5 functions failed for operations using the internal
filename
character set and could cause a
server exit.
(Bug #18786138)
Large arguments passed to mysqldump could lead to buffer overflow and program exit. (Bug #18779944)
If a materialized subquery read from a view, and contained an inner subquery having an outer reference to a column of the view, results could be incorrect. (Bug #18770217)
Passing bad arguments to SHA2()
could cause a server exit.
(Bug #18767104)
Spatial operations on InnoDB
tables could
fail attempting to access nonexistent index statistics.
(Bug #18743725)
ORDER BY
of a GIS function that was given
invalid arguments could cause a server exit.
(Bug #18701868)
The code for processing the gb18030
character
set had a too-strict assertion for single-character invalid
characters.
(Bug #18700668)
After a metadata change, a reprepared trigger could cause a server exit or prune an incorrect partition. (Bug #18684393)
mysql_secure_installation ignored options defined after an unrecognized option. (Bug #18659533)
VALIDATE_PASSWORD_STRENGTH()
could enter an infinite loop for some arguments.
(Bug #18636291)
ALTER TABLE
on a partitioned
table could result in the wrong storage engine being written
into the table's .frm
file and displayed in
SHOW CREATE TABLE
.
(Bug #18618561)
The server could fail to properly reprepare triggers that referred to another table after that table was truncated. (Bug #18596756, Bug #72446, Bug #18665853)
Compiler flags were not passed to DTrace, causing problems for 32-bit builds cross-compiled on 64-bit platforms. (Bug #18593044)
For conditions on the form t.key NOT IN (c1, c2,
...)
, if one or more of the c1
,
c2
was NULL
, the optimizer
generated incorrect range predicates, possibly yielding
incorrect results.
The range optimizer would build predicates for empty in-lists
(because NULL
values are removed from
NOT IN (in-list)
).
(Bug #18556403, Bug #18715670)
After conversion of an in-memory internal temporary table to disk, the server could use a pointer to the old table, resulting in a server exit. (Bug #18535226)
For queries executed using Loose Index Scan, incorrect cost estimates could be produced if index statistics were unavailable. (Bug #18497308)
Setting default_storage_engine
to a bad value could cause server failure later.
(Bug #18487724)
In debug builds, MAKE_SET()
within a GROUP BY
clause raised an assertion.
(Bug #18487060)
In debug builds, subquery optimization could be overly aggressive about raising an assertion. (Bug #18486607)
In debug builds, a qsort operation on decimal values could raise an assertion. (Bug #18486249)
For debug builds, an assertion was raised for attempts using a
cursor within a stored routine to fetch a large value
(INT
) which cannot fit into a variable
(TINYINT
).
(Bug #18484649)
MOD
for very small decimal right-hand
arguments could cause a server exit.
(Bug #18469276)
With the max_heap_table_size
system variable set to a large value (20GB), creation of a
temporary table or a table using the MEMORY
storage engine caused a server exit.
(Bug #18463911)
mysql_session_track_get_first()
and
mysql_session_track_get_next()
returned information only when the type
argument was SESSION_TRACK_SYSTEM_VARIABLES
,
and returned information for all types, not just
SESSION_TRACK_SYSTEM_VARIABLES
. Now they
return information of the type requested and only that type.
(Bug #18463441)
For mysql_upgrade, specifying the
--defaults-extra-file
with a nonexisting file
caused a segmentation fault on some platforms.
(Bug #18443096)
Assigning some values to the
session_track_system_variables
system variable could cause a server exit.
(Bug #18405677)
mysql_install_db could hang while reading
/dev/random
to generate a random
root
password.
(Bug #18395378)
EXPLAIN FOR
CONNECTION
showed an incorrect filtering value for
dynamic range queries.
(Bug #18395059)
The client library now includes a call to
X509_verify_cert_error_string()
in the SSL
certificate verification code, to be more robust in detecting
invalid certificates.
(Bug #18384260)
Queries that use AES_ENCRYPT()
,
AES_DECRYPT()
, or
RANDOM_BYTES()
cannot be cached
but were permitted to enter the query cache.
(Bug #18383169)
If MySQL was built with the
-DINSTALL_LIBDIR=lib64
option,
mysql_config did not work if the MySQL
package was unpacked into a location with a different
installation prefix. Also, mysql_config did
not work for some RPM builds because it used an incorrect
installation prefix.
(Bug #18382225)
Plugin registration code in the embedded server (compiled without the Performance Schema) failed for plugins compiled with the Performance Schema. (Bug #18363910)
For indexes on prefixes or character string columns, index corruption could occur for assignment of binary data to the column due to improper character counting. (Bug #18359924)
The HAVE_IB_LINUX_FUTEX
CMake check failed due to a missing include
file.
(Bug #18353271)
After a code reorganization in MySQL 5.7.4, ORDER
BY
for multiple-table UPDATE
statements was ignored.
(Bug #18352634)
The addition in MySQL 5.7.4 of session state information to the
OK packet of the client/server protocol caused the
mysql->info
member to be missing a
terminating null terminator.
(Bug #18349102)
Improper linking of join caches by the optimizer could lead to a server exit. (Bug #18335908)
In debug builds, lack of proper object initialization of decimal objects caused an assertion to be raised. (Bug #18335446)
UNCOMPRESSED_LENGTH()
could
return NULL
when it should not have.
(Bug #18335269)
On Windows, some test cases ran too slowly due to mysqltest not testing properly for server termination. (Bug #18330694)
The COM_RESET_CONNECTION
command did not
reset some session system variables:
rand_seed1
,
rand_seed2
,
timestamp
. Also, it did not
clear warnings, and, although it reset the
profiling
variable, it did not
reset profiling information.
(Bug #18329348, Bug #18329560, Bug #18328396, Bug #18329452)
Certain INFORMATION_SCHEMA
queries could
cause a server exit.
(Bug #18319790)
EXPLAIN
for some full-text
queries could raise an assertion.
(Bug #18313651)
Solaris-specific scripts were included in and installed by non-Solaris packages. (Bug #18305641)
DELETE
is not allowed on views
defined as joins on the base tables. However, MySQL incorrectly
permitted REPLACE
(which is like
a combination of DELETE
and
INSERT
) on such views.
(Bug #18286777)
For debug builds, a 0x00
character in a
full-text query string that used the
ujis_japanese_ci
,
utf8mb4_turkish_ci
, or
eucjpms_bin
collation could raise an
assertion.
(Bug #18277305)
innobase_strnxfrm()
wrote one byte too many.
(Bug #18277082)
On Windows, use of the gb18030_unicode_520_ci
caused a server exit.
(Bug #18271429)
The internal likely()
and
unlikely()
macros conflicted with Boost
symbols. To resolve this, the macros were converted to inline
functions.
(Bug #18242233)
If the left-hand-side of an IN
predicate was
a scalar subquery but returned no row, the server could exit.
(Bug #18223655, Bug #18447874)
For queries involving an AND
of two geometry
ranges, the optimizer could decide no index was usable but try
to use it anyway, resulting in a server exit.
(Bug #18220153)
Argument checking for a memmove()
call in
my_net_read()
was improved.
(Bug #18184793)
mysql_upgrade invoked the
mysql and mysqlcheck
clients and the command arguments could be visible to other
processes. This issue is addressed by the reimplementation of
mysql_upgrade to communicate directly with
the server, a change described elsewhere in these release notes.
(Bug #18180398)
yaSSL code had an off-by-one error in certificate decoding that could cause buffer overflow.
yaSSL code had an opendir()
without a
corresponding closedir()
.
(Bug #18178997, Bug #17201924)
EXPLAIN
on a query with an
EXISTS
subquery containing a
UNION
could cause a server exit. Multiple
executions of a prepared EXPLAIN
on a
UNION
of subqueries could cause a server
exit.
(Bug #18167356)
mysqladmin password masked the old password given on the command line, but not the new password. (Bug #18163964)
For InnoDB
tables, boolean full-text queries
for terms ending with *
could return
incorrect results.
(Bug #18128757)
For XA transactions, -1 could be assigned as the format ID part of an XID value, resulting in mishandling (server hang or exit) of concurrent XA statements. (Bug #18107853)
The client library could cause clients to exit due to incorrectly mapping the client error number to the corresponding message, if reallocation of packet buffer memory occurred. (Bug #18080920)
For full-text queries on InnoDB
tables,
attempts to access deleted document IDs could lead to a server
exit.
(Bug #18079671)
The optimizer could compute a negative cost value when
constructing an execution plan for MERGE
table queries.
(Bug #18066518)
Executing a correlated subquery on an ARCHIVE
table which has an AUTO_INCREMENT
column
caused the server to hang.
(Bug #18065452)
Calling
mysql_get_server_version()
with
an invalid connection handler argument caused the client to
exit. Now it returns 0 and reports a
CR_COMMANDS_OUT_OF_SYNC
error.
(Bug #18053212)
MyISAM
temporary files could be used to mount
a code-execution attack.
(Bug #18045646)
If the optimizer chose to perform an index scan, in some cases it could choose a noncovering rather than a covering index. (Bug #18035906)
The CMake
-DWITHOUT_PARTITION_STORAGE_ENGINE=1
option did
not work. As part of fixing this problem, a preferred syntax for
disabling storage engines was implmented. The syntax
-DWITH_
is now preferred to
engine
_STORAGE_ENGINE=0-DWITHOUT_
.
For example, use:
engine
_STORAGE_ENGINE=1
-DWITH_EXAMPLE_STORAGE_ENGINE=0 -DWITH_FEDERATED_STORAGE_ENGINE=0 -DWITH_PARTITION_STORAGE_ENGINE=0
Rather than:
-DWITHOUT_EXAMPLE_STORAGE_ENGINE=1 -DWITHOUT_FEDERATED_STORAGE_ENGINE=1 -DWITHOUT_PARTITION_STORAGE_ENGINE=1
(Bug #17947926)
The C client library could leak memory when client plugins were used. (Bug #17933308)
For debug builds, DROP FUNCTION
with a too-long function name raised an assertion.
(Bug #17903490)
A BEFORE UPDATE
trigger could insert
NULL
into a NOT NULL
column.
(Bug #17864349)
A UNION ALL
query with SQL_CALC_FOUND_ROWS
and a
LIMIT
with an offset for one query block
reported an incorrect number of found rows.
(Bug #17833261)
For debug builds, a DELETE
statement with a subquery that returned multiple rows in a
context requiring a scalar subquery could raise a diagnostic
area assertion.
(Bug #17787664)
Using an outer reference in a GROUP BY
or
ORDER BY
clause in a subquery could cause a
server exit.
(Bug #17748273)
For queries that selected from the
events_statements_current
Performance Schema table, adding an ORDER BY
clause could produce incorrect results.
(Bug #17729044)
A (rare) deadlock could occur between
LOCK_thd_data
and the
InnoDB
trx_sys
mutex. One
thread could read a query string while it was being removed by
another thread.
(Bug #17606098)
On Windows, calling mysql_thread_init()
call
without mysql_init()
caused the client to
exit. windows. Now it returns a nonzero result because it is an
error to call mysql_thread_init()
before the
client library is initialized with
mysql_library_init()
.
(Bug #17514920)
For REPLACE
on a view, a row
being replaced in a view might conflict with one or more rows in
the base table, some of which might not be accessible by the
view. In some cases, rows inaccessible by the view could be
replaced.
(Bug #17487701)
mysqldump could create table definitions in
the dump file that resulted in Too many
columns
errors when reloading the dump file.
(Bug #17477959)
Using LOAD DATA
to load
fixed-length data into a view could cause a server exit.
(Bug #17458965)
The optimizer trace could cause a server exit in cases where a subquery was transformed away. (Bug #17458054)
UPDATE
statements that modified
full-text indexes could cause a server exit.
(Bug #17457755)
Sending a SIGQUIT
or
SIGINT
signal to mysql
could result in a glibc
double free or
corruption error.
(Bug #17297324)
A server could have its socket file taken over by a second
server listening on different TCP/IP port but the same socket
file. The socket file also would be unlinked by normal shutdown
of the second server. To avoid this, the server now uses a lock
file with the same name as the socket file and a
.lock
suffix. (For example,
/tmp/mysql.sock
has a lock file of
/tmp/mysql.sock.lock
.) The lock file
contains the process ID of the server process that created the
socket file.
(Bug #17286856)
If a query had both MIN()/MAX()
and
(for example, aggregate_function
(DISTINCT)SUM(DISTINCT)
) and was executed
using Loose Index Scan, the result values of
MIN()/MAX()
were set improperly.
(Bug #17217128)
For UNION
statements, the
rows-examined value was calculated incorrectly. This was
manifest as too-large values for the
ROWS_EXAMINED
column of Performance Schema
statement tables (such as
events_statements_current
).
(Bug #17059925)
When joining one large table without indexes to a number of smaller tables with indexes, the optimizer chose to join on the large table as the last table, causing a large number of large table scans. (Bug #16838146)
Row constructor arguments to
INTERVAL()
could cause a server
exit.
(Bug #16439419)
An assertion could be raised when creating a index on a prefix
of a TINYBLOB
or
GEOMETRY
column in an
InnoDB
column.
(Bug #16368875, Bug #18776592, Bug #17665767)
mysql_config_editor left some files open when they were no longer needed, resulting in Valgrind warnings. (Bug #16368498)
Several issues related to the
ONLY_FULL_GROUP_BY
SQL mode
were corrected:
With ONLY_FULL_GROUP_BY
enabled, some valid queries were rejected if the accessed
table was replaced by a view.
Queries of the form SELECT DISTINCT
qualify as
forbidden by SQL2003 (hidden col1
... ORDER BY
col2
ORDER BY
columns combined with DISTINCT
), but were
not rejected with the
ONLY_FULL_GROUP_BY
SQL
mode enabled.
(Bug #16021396, Bug #18993257, Bug #13581713)
The change made in MySQL 5.7.0 to display the XID value in
hexadecimal for XA
RECOVER
if it contained nonprintable characters was
reverted because it caused problems for some clients. Now the
statement takes an optional CONVERT XID
keyword so that clients can request the XID value in hexadecimal
on demand.
(Bug #14670465)
Use of a nonmultibyte algorithm for skipping leading spaces in multibyte strings could cause a server exit. (Bug #12368495, Bug #18315770)
Executing a DELETE
statement on a table with
no key in safe-update mode resulted in an
ER_UPDATE_WITHOUT_KEY_IN_SAFE_MODE
error. For debug builds, using IGNORE
in the
statement resulted in an assertion being raised.
(Bug #74493, Bug #19873291)
Binary MySQL distributions for OS X 10.8 and up now bundle the
MySQL.prefPane
and
MySQLStartupItem.pkg
tools into the main
package as configurable options instead of separate packages.
(Bug #74123, Bug #19701502)
For debug builds, a SELECT
under
load from the
events_statements_current
Performance Schema table could raise an assertion.
(Bug #73530, Bug #19419463)
mysql_secure_installation failed to run
properly if the root
account authentication
plugin was sha256_password
.
(Bug #73148, Bug #19127636)
The server did not take the
lower_case_table_names
value
into account in determining the database directory from which to
read the db.opts
file, and thus could read
the file from an incorrect directory.
(Bug #72900, Bug #18923685)
SHA2()
failed to return
NULL
if the hash-length argument was
NULL
or not one of the permitted values.
(Bug #72856, Bug #18899869)
mysql_install_db failed to create the initial
root
account if
autocommit
was disabled.
(Bug #72724, Bug #18911807)
The mysql client displayed
gb18030
data incorrectly.
(Bug #72573, Bug #18726196)
The gb18030_chinese_ci
collation treated
'Y'
equal to '~'
.
(Bug #72565, Bug #18729428)
The query cache was not invalidated for a table when a
CASCADE DELETE
or CASCADE
UPDATE
referential constraint was specified and the
database name or table name contained special characters.
(Bug #72547, Bug #18710853)
NOW(
in a view definition was stored as N
)NOW()
,
thus losing the fractional seconds part.
(Bug #72472, Bug #18675237)
If a prepared statement being executed produced an error, the server failed to write the statement to the general query log. (Bug #72375, Bug #18616826)
A new CMake option,
SUNPRO_CXX_LIBRARY
, enables
linking against libCstd
instead of
stlport4
on Solaris 10 or later. This works
only for client code because the server depends on C++98.
Example usage:
cmake -DWITHOUT_SERVER=1 -DSUNPRO_CXX_LIBRARY=Cstd
(Bug #72352, Bug #18605389)
A SELECT
statement using a
subquery with UNION
and ORDER
BY
did not permit use of an alias in the outer
statement.
(Bug #72189, Bug #18498344)
UNION
queries with an aggregate
function in an ORDER BY
clause were not
rejected as they should be. Now such queries are rejected with
an ER_AGGREGATE_ORDER_FOR_UNION
error. Example:
SELECT 1 AS foo UNION SELECT 2 ORDER BY MAX(1);
A nonaggregated query with an ORDER BY
applied to it cannot contain aggregate functions, but was not
rejected as it should be. Now such queries are rejected with an
ER_AGGREGATE_ORDER_NON_AGG_QUERY
error. Example:
SELECT a FROM t1 ORDER BY COUNT(*);
(Bug #72174, Bug #18503515, Bug #72512, Bug #18694751)
MOD
operations on a
DECIMAL
value with leading zeros
could produce incorrect results.
(Bug #72100, Bug #18509896)
mysqlslap accepted an
--iterations
option value of 0, which resulted
in a divide-by-zero error. The minimum option value now is 1.
Thanks to Tsubasa Tanaka for the patch.
(Bug #72082, Bug #18430704)
mysql_upgrade could fail if the
mysql.user
table contained multiple accounts
with the same user name and host name where the host name
differed in lettercase. This is still not permitted, but now
mysql_upgrade prints a more informative error
message to indicate the nature of the problem:
ERROR 1644 (45000): Multiple accounts exist foruser_name
,host_name
that differ only in Host lettercase; remove all except one of them
(Bug #72066, Bug #18415196)
ER_CANT_CREATE_GEOMETRY_OBJECT
was treated as a fatal error, thus not catchable with condition
handlers.
(Bug #72064, Bug #18413646)
Some comparisons between BIGINT
signed and
unsigned values could yield incorrect results.
(Bug #72046, Bug #18408499)
For IN()
predicates with values different
from the key data value, the optimizer sometimes used a table
scan when it could do a range scan.
(Bug #71962, Bug #18364815)
mysql_config_editor exited when given an
empty argument to the --login-path
option.
(Bug #71837, Bug #18311024, Bug #18830493)
Upgrades using RPM packages could change the ownership of an installation directory. (Bug #71715, Bug #18281535)
The threads
Performance Schema
table displayed a PROCESS_ID
value of
NULL
for replication threads. Now it displays
the same ID as SHOW PROCESSLIST
and the
INFORMATION_SCHEMA.PROCESSLIST
table.
(Bug #71682, Bug #18259356)
In the DIGEST_TEXT
column of Performance
Schema statement events tables, references to system variables
of the form
@@
were
stored as var_name
@ @
.
(Bug #71634, Bug #18304086)var_name
For mysqldump, dump and restore operations
failed for database names that contained backslash
('\'
). Thanks to Xiaobin Lin for the patch.
(Bug #71437, Bug #18109728)
A simultaneous OPTIMIZE TABLE
and
online ALTER TABLE
on the same
InnoDB
table could result in deadlock.
(Bug #71433, Bug #18110156)
XA START
after a
server restart with the exising XID followed by
XA COMMIT
failed
to commit.
(Bug #71352, Bug #18068253)
Proxy users were unable to execute statements if the proxied user password had expired. (Bug #71337, Bug #18057562)
MySQL did not compile with Bison 3. (Bug #71250, Bug #18017820, Bug #18978946)
Deadlock could occur if three threads simultaneously performed
INSTALL PLUGIN
,
SHOW VARIABLES
, and
mysql_change_user()
.
(Bug #71236, Bug #18008907, Bug #72870, Bug #18903155)
A statement of the following form broke row-based replication
because it created a table having a field of data type
BIGINT
with a display width of 3000, which is
beyond the maximum acceptable value of 255:
CREATE TABLE t1 AS SELECT REPEAT('A',1000) DIV 1 AS a;
(Bug #71179, Bug #17994219)
When MySQL runs as service on Windows,
NTService.Stop()
initiates shutdown and exit
events during shutdown. After a code reorganization in MySQL
5.7.3, a call to clean_up()
was missed,
resulting in initiation of crash recovery.
(Bug #71104, Bug #17980260)
If there was a predicate on a column referenced by
MIN()
or
MAX()
and that predicate was not
present in all the disjunctions on key parts earlier in the
compound index, Loose Index Scan returned an incorrect result.
(Bug #71097, Bug #17909656)
Invalid memory access could occur when using prepared statements if a mysql client connection was lost after statement preparation was complete and there was at least one statement that was in initialized state but not prepared yet. (Bug #70429, Bug #17512527)
Client auto-reconnect did not work for clients linked against
libmysqlclient
, even with
MYSQL_OPT_RECONNECT
enabled.
Also, if a FEDERATED
table was accessed after
wait_timeout
expired, a Lost
connection to MySQL server
error occurred without an
attempt to re-establish the connection.
(Bug #70026, Bug #17309863, Bug #14874, Bug #11745408)
Full-text queries on MyISAM
tables that
included a LIMIT
clause but no
WHERE
clause could return too few rows.
(Bug #69908, Bug #17261347)
Updates could fail to update all applicable rows in cases where multiple key values were identical except for trailing spaces. (Bug #69684, Bug #17156940)
On Windows, REPAIR TABLE
and
OPTIMIZE TABLE
failed for
MyISAM
tables with .MYD
files larger than 4GB.
(Bug #69683, Bug #17235179)
For logging of prepared statements to the general query log, the
Execute
line was logged after statement
execution, not before.
(Bug #69453, Bug #16953758, Bug #20536590)
Calls to UNCOMPRESS()
produced
Valgrind warnings during verification of the zip header of the
compressed data.
(Bug #69202, Bug #18693654)
mysql_tzinfo_to_sql mishandled some values from the abbreviation list (read from the timezone information file) due to failure to account for the null character appended to the end of the char array. (Bug #68861, Bug #16664462)
Some statements could be written to the slow query log twice. (Bug #68626, Bug #16467055)
File permissions and line endings of several test and configuration files were made more consistent to avoid warnings from package checkers. (Bug #68521, Bug #16415173, Bug #16395459, Bug #68517, Bug #16415032, Bug #71112, Bug #17919313, Bug #71113, Bug #17919422)
In some cases, a successful CREATE
VIEW
could add invalid parentheses to expressions in
the view definition.
(Bug #67791, Bug #15948263)
If the general query log or slow query log file was set to a FIFO or socket file, and the file reader went away, the server stopped executing statements. Now the server detects such files, logs an error message, and continues with the appropriate log disabled. (Bug #67088, Bug #14757009)
For non-debug builds of several client programs, the
--help
message did not correctly indicate that
the --debug
, --debug-check
,
and --debug-info
apply only for debug builds.
(Bug #66854, Bug #16272328)
Notification of events for the general log were received by the audit log plugin only if the general query log was enabled. Now notifications are posted regardless of whether the general query log is enabled. (Bug #60782, Bug #12368204, Bug #20536590, Bug #75796, Bug #20479643)
Queries that used GROUP BY INSERT()
could
produce spurious duplicate-key errors.
(Bug #58081, Bug #11765149)
mysql_install_db could fail if not invoked in the MySQL installation base directory. (Bug #54034, Bug #11761529)
With big_tables
enabled, queries that used
COUNT(DISTINCT)
on a simple join with a
constant equality condition on a non-duplicate key returned
incorrect results.
(Bug #52582, Bug #11760197)
References: See also: Bug #18853696.
LOAD DATA
LOCAL
could use all CPU if import errors occurred when
there were no line delimiters.
(Bug #51840, Bug #11759519)
For an existing nondynamic (built-in) plugin, the error message
for an attempted UNINSTALL PLUGIN
was misleading (the plugin does not exist). Now the message
indicates that built-in plugins cannot be uninstalled.
(Bug #51771, Bug #11759453)
LIKE
matches failed for code points
of HALF WIDTH KATAKANA in the sjis
and
cp932
character sets.
(Bug #47641, Bug #11755818)
The server failed to produce an error for
INSERT
statements that provided
no column names but did provide column values.
(Bug #20943, Bug #11745889, Bug #18064775)
References: This issue is a regression of: Bug #16820562.
Connection IDs are 32-bit unsigned integers, beginning at 1.
When the server assigns connection IDs and reaches the top of
the 32-bit range, it rolls the value over to begin at 1 again.
It was possible that the server would assign a connection ID to
a new thread while that ID was still in use by an existing
thread, if the old thread was particularly long running. For
such cases, reference to the ID becomes ambiguous. For example,
it cannot reliably be determined for
KILL
which thread
to kill, which could lead to undefined behavior. This behavior
has been corrected so that in-use IDs are not reused.
connection_id