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