Functionality Added or Changed
* Performance; InnoDB: Memory for transaction instances (trx_t)
is now allocated in configurable sized blocks that are a
multiple of transaction instance size. Transaction instances
are also placed in a priority queue and ordered by their
address in memory so that when instances are allocated from
the pool, they are close together. This enhancement reduces
the cost incurred by iterating over transactions instances
when allocating instances from the pool.
* Performance; InnoDB: Internal B-tree index operations have
been optimized to reduce index locking contention.
* Performance; InnoDB: Multi-version concurrency control (MVCC
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_mvc
c)) in InnoDB requires that each transaction using MVCC
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_mvc
c) be assigned a read view. To improve InnoDB read-only and
read-write performance, read view creation has been optimized
by reducing mutex contention.
* Performance: Previously, the main loop responsible for
accepting client connections also performed initialization of
data structures related to each connection. These
initialization tasks now are delegated to worker threads to
minimize work done by the accept loop and maximize connection
acceptance rate. (Bug #62288, Bug #12951536, Bug #62284, Bug
#12951595, Bug #62283, Bug #12951605)
* Incompatible Change: The bind_address, thread_cache_size, and
thread_handling system variables as well as the
Slow_launch_threads and Thread_cached status variables are not
meaningful in the embedded server. These variables are no
longer visible within the embedded server and embedded
applications that rely on these variables should be should be
modified accordingly. (Bug #62288, Bug #12951536, Bug #62284,
Bug #12951595, Bug #62283, Bug #12951605)
* Incompatible Change: The unused --basedir and --datadir
options for mysql_upgrade have been removed.
* Important Change; Replication: By default, when promoting
integers from a smaller type on the master to a larger type on
the slave (for example, from a SMALLINT column on the master
to a BIGINT column on the slave), the promoted values are
treated as though they are signed. Now in such cases it is
possible to modify or override this behavior using one or both
of ALL_SIGNED, ALL_UNSIGNED in the set of values specified for
the slave_type_conversions server system variable. For more
information, see Row-based replication: attribute promotion
and demotion
(http://dev.mysql.com/doc/refman/5.7/en/replication-features-d
iffering-tables.html#replication-features-attribute-promotion)
, as well as the description of the variable. (Bug #15831300)
* InnoDB: innochecksum functionality has been enhanced with new
options and extended capabilities. See innochecksum ---
Offline InnoDB File Checksum Utility
(http://dev.mysql.com/doc/refman/5.7/en/innochecksum.html).
(Bug #16945722)
* InnoDB: A new CMake option, WITH_INNODB_EXTRA_DEBUG, has been
added that enables additional InnoDB debug checks.
WITH_INNODB_EXTRA_DEBUG can only be enabled when the
WITH_DEBUG option is also enabled. (Bug #16821155)
* InnoDB: A number of internal debug flags in the InnoDB code
could only be set at compilation time or from a debugger. As a
result, a significant amount of diagnostic information was
unused. This enhancement replaces internal debug flags with
DBUG labels so that the DBUG package
(http://dev.mysql.com/doc/refman/5.7/en/dbug-package.html) can
be used and printouts from various InnoDB subsystems can be
enabled using the mysqld --debug command line option. See the
Debugging a MySQL Server
(http://dev.mysql.com/doc/refman/5.7/en/debugging-server.html)
section for information about configuring MySQL for debugging,
creating trace files, and using the mysqld --debug option.
* InnoDB: The process for converting a transaction's implicit
lock to an explicit lock has been optimized to improve
performance. The optimization reduces lock_sys_t::mutex
contention.
* InnoDB: Beginning with MySQL 5.7.2, UPDATE_TIME displays a
timestamp value for the last UPDATE, INSERT, or DELETE
performed on InnoDB tables. Previously, UPDATE_TIME displayed
a NULL value for InnoDB tables. For MVCC, the timestamp value
reflects the COMMIT time, which is considered the last update
time. Timestamps are not persisted when the server is
restarted or when the table is evicted from the InnoDB data
dictionary cache.
* InnoDB: For SELECT COUNT (*) queries, where a table's
committed record count is changed by transaction deltas, there
is now a single handler call to the storage engine to return
the record count to the optimizer instead of one call for each
record. This change generally improves SELECT COUNT (*) query
performance and reduces in-memory table scan cost, as each
record is no longer returned to the optimizer.
In some instances, however, where there is a large clustered
index and a very small secondary index, performance may not be
improved. Previously, the optimizer would choose to traverse
the smaller secondary index instead of the larger clustered
index. The smaller secondary index could, in this case, offer
better performance than a clustered index with a single
handler call to the storage engine. However, there may be no
performance benefit if the secondary index is often updated.
When a secondary index page is modified by a transaction that
is more recent than the COUNT(*) transaction, InnoDB must read
the clustered index to determine if the record is visible. In
this case, InnoDB would read both the secondary and clustered
index, which is costlier than reading only the clustered
index.
* InnoDB: Read-only transactions will no longer be assigned a
transaction ID. Conversely, an ID will only be assigned if a
transaction is explicitly tagged as "read-write", if a
transaction has acquired an X or IX lock on a table, or if a
transaction is a read-only transaction writing to a temporary
table. All other transactions are considered "read-only" and
are not assigned an ID. Furthermore, read-only transactions
are not tagged as "read-only" unless they are explicitly
started with START TRANSACTION READ ONLY. For transactions
without transaction IDs, SHOW ENGINE INNODB STATUS prints an
identifier that is unique but only within the context of the
SHOW ENGINE INNODB STATUS invocation.
* InnoDB: MySQL 5.7.2 introduces a new type of undo log for both
normal and compressed temporary tables and related objects.
The new type of undo log is not a redo log, as temporary
tables are not recovered during crash recovery and do not
require redo logs. The new undo log
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_und
o_log) resides in the temporary tablespace. The default
temporary tablespace file, ibtmp1, is located in the data
directory by default and is always recreated on server
startup. A user defined location for the temporary tablespace
file can be specified by setting innodb_temp_data_file_path.
For more information, see InnoDB Temporary Table Undo Logs
(http://dev.mysql.com/doc/refman/5.7/en/innodb-temporary-table
-undo-logs.html).
* InnoDB: The limit on concurrent data-modifying transactions
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_tra
nsaction) is now 96 * 1023 transactions that generate undo
records
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_und
o_log). As of MySQL 5.7.2, 32 of 128 rollback segments
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_rol
lback_segment) are allocated to non-redo logs for transactions
that modify temporary tables and related objects. This reduces
the maximum number of concurrent data-modifying transactions
from 128K to 96K. The 96K limit assumes that transactions do
not modify temporary tables. If all data-modifying
transactions also modify temporary tables, the limit would be
32K concurrent transactions.
* InnoDB: DML operations (INSERT, UPDATE, DELETE) for temporary
tables have been optimized by turning off redo logging,
locking, and change buffering that is not required for
temporary tables. Turning off these functions optimizes
temporary table DML operations by reducing associated I/O.
* InnoDB: InnoDB buffer pool dump and load operations have been
enhanced. A new system variable, innodb_buffer_pool_dump_pct,
allows you to specify the percentage of most recently used
pages in each buffer pool to read out and dump. When there is
other I/O activity being performed by InnoDB background tasks,
InnoDB attempts to limit the number of buffer pool load
operations per second using the innodb_io_capacity setting.
* InnoDB: Buffer pool list scans and related batch processing
have been optimized to reduce scan complexity and the number
of pages scanned. For more information, see Buffer Pool List
Scan and Batch Processing Optimization
(http://dev.mysql.com/doc/refman/5.7/en/innodb-performance.htm
l#innodb-performance-buffer-pool-scan-optimization).
* InnoDB: Refactored mutex code makes selecting the appropriate
mutex easier and allows multiple mutex types to be combined in
the same instance. The refactored code also removes the
distinction between fast_mutex_t and home brew ib_mutex_t
types, implements a common interface for both mutex types, and
allows new mutex types to be added in the future.
Additionally, mutex code is decoupled from InnoDB code so that
it can be used as a library, and a "PolicyMutex" interface has
been introduced. The new interface uses static inheritance
(templates) for mutex implementation making it easier to
define policies and customize mutex behavior.
* Partitioning: The following operations are now supported for
individual subpartitions as well as partitions: ANALYZE,
CHECK, OPTIMIZE, REBUILD, REPAIR, and TRUNCATE (see ALTER
TABLE Partition Operations
(http://dev.mysql.com/doc/refman/5.7/en/alter-table-partition-
operations.html)). (Bug #14028340, Bug #65184)
* Replication: Previously, transactions could be applied in
parallel only if they did not touch the same database.
However, the MySQL Server uses a lock-based scheduler, which
means that it should be possible to execute in parallel all
uncommitted replication threads already in the prepare phase,
without violating consistency. Such parallel execution can now
be enabled on the slave by starting the slave mysqld with
--slave-parallel-type=LOGICAL_CLOCK or, if mysqld is already
started, by setting the value of the global system variable
slave_parallel_type to 'LOGICAL_CLOCK' on a stopped slave.
When this feature is enabled, each transaction is marked with
a logical timestamp. This timestamp identifies the last
transaction committed at the time that the current transaction
entered the prepare stage, and all transactions having the
same timestamp can execute in parallel.
To disable this feature without restarting, stop the slave
using STOP SLAVE (if it is running as a slave), issue SET
@global-slave_parallel_type='DATABASE', then issue START SLAVE
when you want the slave to resume. You can also disable the
feature by restarting the slave mysqld without the
--slave-parallel-type option, or by setting it explicitly to
DATABASE. When parallel execution of preapred transactions is
disabled, the slave follows the old behavior and applies in
parallel only those transactions that do not cause changes in
the same database.
* Support for LinuxThreads has been removed from the source
code. LinuxThreads was superseded by NPTL in Linux 2.6. (Bug
#17007529)
* Support for building Apple universal binaries to support
PowerPC has been removed from the source code. (Bug #16959103)
* CMake no longer checks for memmove() or memcpy() because they
are standard C library functions. Also, implementation of the
bmove_upp() function was replaced with calls to memmove(),
which may have positive performance implications. (Bug
#16839824)
* The C API libmysqlclient shared-library .so files now have
version 18.1.0 (up from version 18.0.0 used in MySQL 5.5).
18.1.0 can be used as a replacement for 18.0.0. (Bug
#16809055)
* Use of DYNAMIC_ARRAY was reduced, which improves performance
of certain range queries by 3-4%. (Bug #16736776, Bug
#17030235)
* mysql_upgrade now verifies that the server version matches the
version against which it was compiled, and exits if there is a
mismatch. In addiion, a --version-check option permits
specifying whether to enable version checking (the default),
or disable checking if given as --skip-version-checking. (Bug
#16500013)
* mysqladmin now supports a --show-warnings option to display
warnings resulting from execution of statements sent to the
server. (Bug #16517756)
* The following items are deprecated and will be removed in a
future MySQL release. Where alternatives are shown,
applications should be updated to use them.
+ The ENCODE() and DECODE() functions. Use AES_ENCRYPT()
and AES_DECRYPT() instead.
+ The INFORMATION_SCHEMA.PROFILING table. Use the
Performance Schema instead; see MySQL Performance Schema
(http://dev.mysql.com/doc/refman/5.7/en/performance-schem
a.html).
(Bug #16463921)
* Invoking CMake with -DWITH_AUTHENTICATION_PAM=1 now causes the
build to fail (rather than issue only a warning) if the PAM
plugin cannot be built. (Bug #14554639)
* In batch mode, mysql formatted result status messages such as
""Query OK, 1 row affected"" but did not print them. Now these
messages are not formatted. (Bug #69486, Bug #16971432)
* Several inefficiencies were corrected:
+ A loop in Item_in_subselect::single_value_transformer()
could execute too many times.
+ The myisamchk(), my_test_if_sort_rep(), and
recreate_table() functions in MyISAM code could execute
too many times.
Thanks to Po-Chun Chang for the patches to correct these
issues. (Bug #69138, Bug #16764131, Bug #69117, Bug #16751784,
Bug #69561, Bug #17007268, Bug #69553, Bug #17001703)
* Plugins can now define and expose floating-point system
variables of type double using the MYSQL_SYSVAR_DOUBLE() and
MYSQL_THDVAR_DOUBLE() accessor macros. See Client Plugin
Descriptors
(http://dev.mysql.com/doc/refman/5.7/en/plugin-data-structures
.html#client-plugin-descriptors). (Bug #68121, Bug #16194302)
* Semi-join LooseScan strategy now can use ref access and
applies to a wider range of queries.
* EXPLAIN can now be used to obtain the execution plan for an
explainable statement executing in a named connection:
EXPLAIN [options] FOR CONNECTION connection_id;
For example, if you are running a statement in one session
that is taking a long time to complete, using EXPLAIN FOR
CONNECTION in another session may yield useful information
about the cause of the delay and help you optimize the
statement.
connection_id is the connection identifier, as obtained from
the INFORMATION_SCHEMA PROCESSLIST table or the SHOW
PROCESSLIST statement. If you have the PROCESS privilege, you
can specify the identifier for any connection. Otherwise, you
can specify the identifier only for your own connections.
Changes in EXPLAIN output:
+ In the output from EXPLAIN FOR CONNECTION, an Extra value
of Plan isn't ready yet means that the optimizer has not
finished creating the execution plan for the statement
executing in the named connection. (For JSON-format
output, this is indicated by planned: false.)
+ In the output from any EXPLAIN used to obtain the
execution plan for non-SELECT statements, the select_type
value displays the statement type for affected tables.
For example, select_type is DELETE for DELETE statements.
For more information, see EXPLAIN Syntax
(http://dev.mysql.com/doc/refman/5.7/en/explain.html).
* To make it easier to see the difference between good and bad
execution plans, JSON-format EXPLAIN output now includes this
additional cost information:
+ query_cost: The total cost of a query block, whether a
top-level query or subquery. For a top-level SELECT, this
should be equal to the Last_query_cost status variable.
+ sort_cost: The cost of the first sorting operation (GROUP
BY or ORDER BY) where and if filesort is used.
+ read_cost: The cost of reading data from each table used
in the query block (that is, access method cost).
+ eval_cost: The cost of condition evaluation for each
table in the query block.
+ prefix_cost: The cost of executing prefix join in the
query block; that is, the cost of joining tables of the
query block from the first one to the one (and including
it) for which the value is given.
+ data_read_per_join: The estimated amount of data
processed by the handler interface per query or subquery
execution. This is essentially record width * number of
read records.
+ rows_produced_per_join/ rows_examined_per_join: The
estimated number of records from the table (per table
from the query block) produced or examined per single
query block execution.
+ used_columns: The list of columns from the table (per
each table in the query block) used for either read or
write in the query.
This cost information is not displayed for INFORMATION_SCHEMA
tables.
* MySQL supports the use of client-side plugins that implement a
trace of communication between a client and the server that
takes place using the client/server protocol. Protocol trace
plugins use the client plugin API (see Writing Plugins
(http://dev.mysql.com/doc/refman/5.7/en/writing-plugins.html))
.
In MySQL source distributions, a test protocol trace plugin is
implemented in the test_trace_plugin.cc file in the libmysql
directory. This can be examined as a guide to writing other
protocol trace plugins.
Bugs Fixed
* Performance; Important Change; InnoDB: InnoDB would fail to
open a tablespace that has multiple data files. This removes
the known limitation that was in MySQL Server 5.6.12. (Bug
#17033706, Bug #69623)
* Performance; InnoDB: A code regression introduced in MySQL 5.6
negatively impacted DROP TABLE and ALTER TABLE performance.
This could cause a performance drop between MySQL Server 5.5.x
and 5.6.x. (Bug #16864741, Bug #69316)
* Performance; InnoDB: When innodb_thread_concurrency is set to
a non-zero value, there was a possibility that all
innodb_concurrency_tickets would be released after each row
was read, resulting in a concurrency check after each read.
This could impact performance of all queries. One symptom
could be higher system CPU usage. We strongly recommend that
you upgrade to MySQL Server 5.6.13 if you use this setting.
This could cause a performance drop between MySQL Server 5.5.x
and 5.6.x. (Bug #68869, Bug #16622478)
* Incompatible Change: When used for an existing MySQL account,
the GRANT statement could produce unexpected reults if it
included an IDENTIFIED WITH clause that named an
authentication plug differing from the plugin named in the
corresponding mysql.user table row.
Because IDENTIFIED WITH is intended for GRANT statements that
create a new user, it is now prohibited if the named account
already exists. (Bug #16083276)
* Incompatible Change: It is possible for a column DEFAULT value
to be valid for the sql_mode value at table-creation time but
invalid for the sql_mode value when rows are inserted or
updated. Example:
SET sql_mode = '';
CREATE TABLE t (d DATE DEFAULT 0);
SET sql_mode = 'NO_ZERO_DATE,STRICT_ALL_TABLES';
INSERT INTO t (d) VALUES(DEFAULT);
In this case, 0 should be accepted for the CREATE TABLE but
rejected for the INSERT. However, the server did not evaluate
DEFAULT values used for inserts or updates against the current
sql_mode. In the example, the INSERT succeeds and inserts
'0000-00-00' into the DATE column.
The server now applies the proper sql_mode checks to generate
a warning or error at insert or update time.
A resulting incompatibility for replication if you use
statement-based logging (binlog_format=STATEMENT) is that if a
slave is upgraded, a nonupgraded master will execute the
preceding example without error, whereas the INSERT will fail
on the slave and replication will stop.
To deal with this, stop all new statements on the master and
wait until the slaves catch up. Then upgrade the slaves
followed by the master. Alternatively, if you cannot stop new
statements, temporarily change to row-based logging on the
master (binlog_format=ROW) and wait until all slaves have
processed all binary logs produced up to the point of this
change. Then upgrade the slaves followed by the master and
change the master back to statement-based logging. (Bug
#68041, Bug #16078943)
* Important Change; Replication: When the server was running
with --binlog-ignore-db and SELECT DATABASE() returned NULL
(that is, there was no currently selected database),
statements using fully qualified table names in dbname.tblname
format were not written to the binary log. This was because
the lack of a currently selected database in such cases was
treated as a match for any possible ignore option rather than
for no such option; this meant that these statements were
always ignored.
Now, if there is no current database, a statement using fully
qualified table names is always written to the binary log.
(Bug #11829838, Bug #60188)
* InnoDB; Partitioning: Following any query on the
INFORMATION_SCHEMA.PARTITIONS table, InnoDB index statistics
as shown in the output of statements such as SHOW INDEX were
updated, even with innodb_stats_on_metadata=OFF. (Bug
#16860588)
* InnoDB; Partitioning: Joins involving partitioned InnoDB
tables having one or more BLOB columns were not always handled
correctly. The BLOB column or columns were not required to be
join columns, or otherwise to be named or referenced in the
statement containing the join, for this issue to occur. (Bug
#16367691)
* InnoDB; Replication: Trying to update a column, previously set
to NULL, of an InnoDB table with no primary key caused
replication to fail on the slave with Can't find record in
'table'.
Note
This issue was inadvertently reintroduced in MySQL 5.6.6, and
fixed again in MySQL 5.6.12.
(Bug #11766865, Bug #60091)
References: See also Bug #16566658.
* InnoDB: When logging the delete-marking of a record during
online ALTER TABLE...ADD PRIMARY KEY, InnoDB writes the
transaction ID to the log as it was before the deletion or
delete-marking of the record. When doing this, InnoDB would
overwrite the DB_TRX_ID field in the original table, which
could result in locking issues. (Bug #17316731)
* InnoDB: The row_sel_sec_rec_is_for_clust_rec function would
incorrectly prepare to compare a NULL column prefix in a
secondary index with a non-NULL column in a clustered index.
(Bug #17312846)
* InnoDB: An incorrect purge would occur when rolling back an
update to a delete-marked record. (Bug #17302896)
* InnoDB: An assertion failure would occur while searching an
index tree and traversing multiple levels where a block is
accessed or pinned at each level. (Bug #17315967)
* InnoDB: In Windows 64-bit debug builds, read view COPY_TRX_IDS
would report a "vector subscript out of range" error to
standard error output. (Bug #17320056)
* InnoDB: The assertion ut_ad(oldest_lsn <= cur_lsn) in file
buf0flu.cc would fail because the current max LSN would be
retrieved from the buffer pool before the oldest LSN. (Bug
#17252421)
* InnoDB: InnoDB memcached add and set operations would perform
more slowly than SQL INSERT operations. (Bug #17214191)
* InnoDB: As commented in log0log.h, old_lsn and old_buf_free
should only be compiled when UNIV_LOG_DEBUG is enabled. (Bug
#17160270, Bug #69724)
* InnoDB: Before dropping an index, a check is performed to
ensure the index root page is free. If the index root page is
free, dropping activity is avoided. A transaction would be
initialized before the check is performed. If the check
evaluated to true, the initialized transaction would be left
in a dangling state. (Bug #17076822)
* InnoDB: InnoDB would rename a user-defined foreign key
constraint containing the string "_ibfk_" in its name,
resulting in a duplicate constraint. (Bug #17076737, Bug
#69693, Bug #17076718, Bug #69707)
* InnoDB: When started in ready-only mode, InnoDB would assert
on a SAVEPOINT. (Bug #17086428)
* InnoDB: In debug builds, the trx_sys->rw_max_trx_id variable
would sometimes be reversed resulting in an inconsistent
CLUST_INDEX_SIZE value. (Bug #17026780)
* InnoDB: An InnoDB monitor test would raise an assertion in
ha_innodb.cc due to a mutex conflict. (Bug #17027249)
* InnoDB: A regression introduced in the fix for Bug #14606334
would cause crashes on startup during crash recovery. (Bug
#16996584)
* InnoDB: Rolling back an INSERT after a failed BLOB write would
result in an assertion failure. The assertion has been
modified to allow NULL BLOB pointers if an error occurs during
a BLOB write. (Bug #16971045)
* InnoDB: The ha_innobase::clone function would incorrectly
assert that a thread cannot clone a table handler that is used
by another thread, and that the original table handler and the
cloned table handler must belong to the same transaction. The
incorrect assertions have been removed. (Bug #17001980)
* InnoDB: To avoid namespace clashes, usage of 'using namespace
std' has been removed from InnoDB. (Bug #16899560)
* InnoDB: Optimized explicit record locking routines. (Bug
#16880127)
* InnoDB: The server would crash during a memcached set
operation. The failure was due to a padded length value for a
utf8 char column. During a memcached update operation, a field
from an old tuple would be copied with a data length that was
less than the padded utf8 char column value. This fix ensures
that old tuples are not copied. Instead, a new tuple is
created each time. (Bug #16875543)
* InnoDB: When CHECK TABLE found a secondary index that
contained the wrong number of entries, it would report an
error but not mark the index as corrupt. CHECK TABLE now marks
the index as corrupt when this error is encountered, but only
the index is marked as corrupt, not the table. As a result,
only the index becomes unusable until it is dropped and
rebuilt. The table is unaffected. (Bug #16914007)
* InnoDB: InnoDB would attempt to gather statistics on partially
created indexes. (Bug #16907783)
* InnoDB: A full-text search using the IN BOOLEAN MODE
(http://dev.mysql.com/doc/refman/5.7/en/fulltext-boolean.html)
modifier would result in an assertion failure. (Bug #16927092)
References: This bug is a regression of Bug #16516193.
* InnoDB: SHOW ENGINE INNODB STATUS output would reference a
thread in hex format (example: thread handle 0x880) while the
same thread would be referenced in the SHOW ENGINE INNODB
STATUS transaction list using a decimal format (example:
thread id 2176). (Bug #16934269, Bug #69437)
* InnoDB: When dropping all indexes on a column with multiple
indexes, InnoDB would fail to block a DROP INDEX operation
when a foreign key constraint requires an index. (Bug
#16896810)
* InnoDB: The two INFORMATION_SCHEMA tables for the InnoDB
buffer pool could show an invalid page type for read-fixed
blocks. This fix will show the unknown page type for blocks
that are I/O-fixed for reading. (Bug #16859867)
* InnoDB: InnoDB record comparison functions have been
simplified and optimized. (Bug #16852278)
* InnoDB: innochecksum would ignore the return value of fwrite
which could result in an error or generate warnings and
compilation errors when WITH_INNODB_EXTRA_DEBUG CMake is
enabled. (Bug #16872677)
* InnoDB: An assertion in row0mysql.cc, which ensures that the
dictionary operation lock is not taken recursively, would
fail. (Bug #16862290)
* InnoDB: An assertion failure would occur in file row0log.cc on
ROW_FORMAT=REDUNDANT tables that contained an unexpected but
valid data directory flag. (Bug #16863098)
* InnoDB: Removed invalid compilation warning messages that
appeared when compiling the InnoDB memcached plugin. (Bug
#16816824)
* InnoDB: The page_zip_validate() debug function, which is
enabled when UNIV_ZIP_DEBUG is defined at compilation time,
invokes page_zip_decompress(), which in turn would update some
compression statistics. This would cause some mysql-test-run
tests to fail. (Bug #16759605)
* InnoDB: Valgrind testing returned memory leak errors which
resulted from a regression introduced by the fix for Bug
#11753153. The dict_create_add_foreign_to_dictionary function
would call pars_info_create but failed to call pars_info_free.
(Bug #16754901)
* InnoDB: In debug builds, an online ALTER TABLE operation that
performed a full table copy would raise an assertion. The
assertion was due to a race condition that would occur during
BLOB retrieval, when applying the table modification log to
any log block except for the very last one. This fix modifies
row_log_table_apply_convert_mrec() to ensure that an index
B-tree lock is acquired to protect the access to log->blobs
and the BLOB page. (Bug #16774118)
* InnoDB: When the function trx_rollback_or_clean_recovered()
rolls back or cleans up transactions during a crash recovery,
it removes the trx objects from the trx_sys list without
freeing up the memory used by those objects. To prevent a
memory leak, this fix adds trx_free_for_background() calls to
trx_rollback_resurrected(), the function that removes the trx
objects. (Bug #16754776)
* InnoDB: During an insert buffer merge, InnoDB would invoke
lock_rec_restore_from_page_infimum() on a potentially invalid
record pointer. (Bug #16806366)
* InnoDB: This patch removes the UNIV_INTERN function, which was
introduced in MySQL 5.1 to help replace static linking in
InnoDB with the shared object plugin. UNIV_INTERN is no longer
required. (Bug #16781511)
* InnoDB: The innodb_rwlock_x_spin_waits item in the
INFORMATION_SCHEMA.INNODB_METRICS table would show the same
value as the innodb_rwlock_x_os_waits item. (Bug #16798175)
* InnoDB: In debug builds, an assertion could occur in
OPT_CHECK_ORDER_BY when using binary directly in a search
string, as binary may include NULL bytes and other
non-meaningful characters. This fix will remove non-meaningful
characters before the search is run. (Bug #16766016)
* InnoDB: The trx_tables_locked counter in
INFORMATION_SCHEMA.INNODB_TRX would not account for all tables
with locks. (Bug #16793724)
* InnoDB: A missing comma in SHOW STATUS output would break
MySQL Enterprise Monitor parsing. (Bug #16723686)
* InnoDB: After a clean shutdown, InnoDB does not check .ibd
file headers at startup. As a result, in a crash recovery
scenario, InnoDB could load a corrupted tablespace file. This
fix implements consistency and status checks to avoid loading
corrupted files. (Bug #16720368)
* InnoDB: A memory leak would occur in
dict_check_tablespaces_and_store_max_id() when space_id is
equal to zero. (Bug #16737332)
* InnoDB: Some characters in the identifier for a foreign key
constraint
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_for
eign_key_constraint) are modified during table exports. (Bug
#16722314, Bug #69062)
* InnoDB: The page_zip_validate() consistency check would fail
after compressing a page, in page_zip_compress(). This problem
was caused by page_zip_decompress(), which would fail to set
heap_no correctly when a record contained no user data bytes.
A record with no user data bytes occurs when, for example, a
primary key is an empty string and all secondary index fields
are NULL or an empty string. (Bug #16736929)
* InnoDB: This patch is a code cleanup which may provide a minor
performance improvement when keys are not used on columns and
when using the default latin1_swedish_ci collation. (Bug
#16723431)
* InnoDB: A regression introduced with the fix for Bug #11762038
would cause InnoDB to raise an incorrect error message. The
message stated that, "InnoDB cannot delete/update rows with
cascading foreign key constraints that exceed max depth of
20". The error message would occur when killing connections
reading from InnoDB tables that did not have foreign key
constraints. (Bug #16710923)
* InnoDB: In debug builds, an assertion failure would occur if
innodb_log_group_home_dir does not exist. Instead of an
assertion, InnoDB now aborts with an error message if
innodb_log_group_home_dir does not exist. (Bug #16691130, Bug
#69000)
* InnoDB: Stale InnoDB memcached connections would result in a
memory leak. (Bug #16707516, Bug #68530)
* InnoDB: An INSERT into a temporary table resulted in the
following assert: ASSERT ID > 0 IN TRX_WRITE_TRX_ID(). This
fix corrects conditions for moving a transaction from a
read-only list to a read-write list when the server is running
in read-only mode. (Bug #16660575)
* InnoDB: A race condition would occur between ALTER TABLE ...
ADD KEY and INSERT statements, resulting in an "Unable to
Purge a Record" error. (Bug #16628233)
* InnoDB: Shutting down and restarting InnoDB with
--innodb-force-recovery set to 3 or greater (4, 5, or 6) and
attempting to drop a table would result in a crash. With
innodb_force_recovery mode set to 3 or greater DML operations
should be blocked and DDL operations allowed. This fix ensures
that DDL operations are allowed. (Bug #16631778)
* InnoDB: A full-text search that returns large result sets
would consume an excessive amount of memory due to use of a
red-black tree for holding full-text search results. This fix
reduces and imposes a limit on memory consumption. If the
limit is exceeded, a message is returned indicating that the
full-text search query exceeds the maximum allowed memory.
(Bug #16625973)
* InnoDB: An existing full-text index would become invalid after
running ALTER TABLE ADD FULLTEXT due to an unsynchronized
full-text cache. (Bug #16662990, Bug #17373659)
* InnoDB: When ADD PRIMARY KEY columns are reordered in an ALTER
TABLE statement (for example: ALTER TABLE t1 ADD PRIMARY
KEY(a,b), CHANGE a a INT AFTER b), the log apply for UPDATE
operations would fail to find rows. (Bug #16586355)
* InnoDB: DML operations on compressed temporary tables would
result in a Valgrind error in the buffer manager stack. (Bug
#16593331)
* InnoDB: In debug builds, the assert_trx_in_list() assert would
fail, causing a race condition. This fix removes the assert.
The same assert is verified in the caller and existing checks
are sufficient. (Bug #16567258)
* InnoDB: A code regression resulted in a record lock wait in a
dictionary operation. A code modification made to avoid
starting a transaction on a temporary table failed to reset
the state back to init upon completion of the operation. If a
transaction is started, the state is usually reset by
trx_commit. To catch similar problems in the future, this fix
adds asserts to innobase_commit(), innobase_rollback(), and
ha_innobase::update_thd() that trigger when
trx->dict_operation and trx->dict_operation_lock_mode are not
set. (Bug #16575799)
* InnoDB: This fix addresses a race condition that would occur
between the rollback of a recovered transaction and creation
of a secondary index in a locked operation. The race condition
would corrupt the secondary index. (Bug #16593427)
* InnoDB: The MySQL printf facility (my_vsnprintf) did not
understand the Microsoft I32 and I64 integer format width
specifiers, such as %I64u for printing a 64-bit unsigned
integer. As a result, DBUG_PRINT could not be used with the
InnoDB UINT64PF format, which is defined as %I64u on Windows.
This fix replaces the non-standard "I64" and "I32" length
modifiers on Windows with "ll" and "l" so that they will be
understood by both my_snprintf() and ut_snprintf(). (Bug
#16559119)
* InnoDB: ALTER TABLE operations on InnoDB tables that added a
PRIMARY KEY using a column prefix could produce an incorrect
result. (Bug #16544336)
* InnoDB: For ALTER TABLE operations on InnoDB tables that
required a table-copying operation, other transactions on the
table might fail during the copy. However, if such a
transaction issued a partial rollback, the rollback was
treated as a full rollback. (Bug #16544143)
* InnoDB: Under certain circumstances, LRU flushing would take a
long time possibly affecting all flushing activity and causing
a shutdown timeout. (Bug #16500209)
* InnoDB: The recv_writer thread would only start after all redo
log scans finished. In the case of multiple redo log scans,
accumulated redo records would be applied after each scan and
before processing the next scan. The absence of the
recv_writer thread to help with flushing would slow recovery
or result in a server startup timeout. This fix ensures that
the recv_writer thread starts before the first scan batch is
processed. (Bug #16501172)
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql