MySQL Lists are EOL. Please join:

List:Announcements« Previous MessageNext Message »
From:Bjorn Munch Date:September 21 2013 4:07pm
Subject:MySQL Community Server 5.7.2 has been released (part 2 of 4)
View as plain text  
   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
       c)) in InnoDB requires that each transaction using MVCC
       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
       , 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
       (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
       ( 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
       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

     * 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

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

     * InnoDB: The limit on concurrent data-modifying transactions
       nsaction) is now 96 * 1023 transactions that generate undo
       o_log). As of MySQL 5.7.2, 32 of 128 rollback segments
       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

     * 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,
       TABLE Partition Operations
       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

     * 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

     * 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

     * Use of DYNAMIC_ARRAY was reduced, which improves performance
       of certain range queries by 3-4%. (Bug #16736776, Bug

     * 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

     * 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
       (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
       .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
       connection_id is the connection identifier, as obtained from
       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

     * 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

     * 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
       In MySQL source distributions, a test protocol trace plugin is
       implemented in the 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 = '';
       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

     * 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

     * 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
       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 would fail because the current max LSN would be
       retrieved from the buffer pool before the oldest LSN. (Bug

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

     * 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

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

     * 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, which ensures that the
       dictionary operation lock is not taken recursively, would
       fail. (Bug #16862290)

     * InnoDB: An assertion failure would occur in file 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

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

     * 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

     * 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

     * 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

     * 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 Community Server 5.7.2 has been released (part 2 of 4)Bjorn Munch22 Sep