New version of MySQL 5.6.22
# Functionality Added or Changed
* Replication: The variable binlogging_impossible_mode has been renamed binlog_error_action. binlogging_impossible_mode is now deprecated.
* The new -DWITH_UBSAN=ON CMake option enables the Undefined Behavior Sanitizer. This feature is supported by GCC 4.9 and up, and Clang 3.4 and up.
# Bugs Fixed
* InnoDB: An ALTER TABLE operation raised an assertion. When a foreign key object was removed from the dictionary cache, an incorrect foreign key object was removed from the rb-tree.
* InnoDB: In debug builds, setting the innodb_limit_optimistic_insert_debug debug configuration option to 1 caused an infinite B-tree page split.
* InnoDB: The dict_set_corrupted() function attempted to update the clustered index of the SYS_INDEXES data dictionary table incorrectly.
* InnoDB: Pages with a checksum value of zero were incorrectly treated as empty pages. A page should only be considered empty if its checksum value and LSN field values are zero.
* InnoDB: The InnoDB data dictionary was not updated when a ALTER TABLE ... CHANGE COLUMN operation changed the case of the column name.
* InnoDB: A memory access violation caused fts_optimize_thread and mysqld to terminate. (Bug #19314480)
* InnoDB: A procedure, called from a function to perform an operation on a temporary table, caused the server to halt.
* InnoDB: Attempting to shut down the server after starting the server with innodb_force_recovery=6 resulted in a hang.
* InnoDB: A COMMIT operation related to full-text search resulted in a segmentation fault. (Bug #18503734)
* InnoDB: If a database is named using uppercase letters on a MySQL server with lower_case_table_names=2 (which is default on Mac OS X), InnoDB stores the database name as specified in the InnoDB internal system table (SYS_TABLES) but stores the name in lowercase on disk. During crash recovery, the case mismatch resulted in a conflict that would mark the tablespace .ibd file as missing. The patch for this bug converts database names to lowercase on crash recovery.
* InnoDB: In debug builds, the InnoDB Lock Monitor asserted after a DROP TABLE operation, and the InnoDB Monitor encountered an assertion in buf_page_get_gen. (Bug #18062698, Bug #71343, Bug #18173184, Bug #68116)
* InnoDB: A CREATE TABLE operation that failed with innodb_strict_mode=ON would succeed without printing a warning with innodb_strict_mode=OFF. (Bug #17852083)
* InnoDB: For explicit cache coherency, a write barrier was added to the head of os_thread_create_func(), and a read barrier was added to before the assertion code in rw_lock_free_func(). (Bug #13364876, Bug #62692, Bug #18870970, Bug #72809)
* InnoDB: The MySQL 5.6.20 patch for Bug #16963396 / MySQL Bug #69477 limited the size of redo log BLOB writes to 10% of the redo log file size. This limitation has been relaxed. Redo log BLOB writes are now limited to 10% of the total redo log size (innodb_log_file_size * innodb_log_files_in_group). As a result, innodb_log_file_size * innodb_log_files_in_group should be 10 times larger than the largest BLOB data size found in the rows of your tables plus the length of other variable length fields (VARCHAR, VARBINARY, and TEXT type fields). No action is required if innodb_log_file_size * innodb_log_files_in_group is already sufficiently large or if your tables contain no BLOB data. (Bug #73707, Bug #19498877)
* Partitioning: When multiple columns are used in KEY partitioning, their order may help determine the partition in which the row is placed. Changing this order by means of an ALTER TABLE that uses ALGORITHM=INPLACE can lead to inconsistency when placing rows in partitions; in other words, a row inserted before such an operation operation is placed in one partition, but the same row inserted afterwards is placed in a different one. For this reason, altering the order of a multicolumn index online is no longer allowed when that index is also used as the base for partitioning the table by KEY; instead, you must use a copying ALTER TABLE to perform the change.
* Replication: When using a MySQL version that had been compiled with the WITH_DEBUG option enabled, using expire_logs_days to purge binary logs caused a restart to crash the server. This problem arose after the fix for Bug #17283409. The fix ensures that current_thd is checked before calling DEBUG_SYNC().
* Replication: Sometimes the slave I/O thread leaves a partial group in the current relay log, for example when it is killed or stopped. After it is restarted, a new relay log is created on rotation and a pair of ROTATE_EVENT and FORMAT_DESCRIPTION_EVENT is replicated from master and written into the new relay log. When using a multi-threaded slave, problems such as error 1755 were encountered when applying the remaining part of the group in the relay log. This fix ensures that if MASTER_AUTO_POSITION is enabled, then the worker rolls back the partial group, finishes its work, and then applies the new complete copy of the group. If MASTER_AUTO_POSITION is disabled, the worker does not roll back the partial group.
* Replication: When using row-based replication with slave_type_conversions enabled, a binary log with more than one Rows_log_event in succession caused a crash. This was due to the temporary tables generated as part of the slave_type_conversions process being released too early. This fix ensures that the temporary tables are not released too early, and also ensures that long transactions do not cause an out of memory error.
* Replication: When using binary log files that had been manually copied from the master, for example to avoid I/O thread reading delay, the multi-threaded slave generated error 1755. Because the Previous_gtid_log_event is logged using the master's server_id and not the slave's server_id, the previous events were not being skipped correctly. This fix ensures that the events in Previous_gtid_log_event are always skipped, regardless of whether they are from the relay log (generated on the slave) or from the binary log (generated on the master and manually copied to the slave as the relay log).
* Replication: When replicating from an earlier version MySQL master, such as version 4.1, checksums are not used for events. Replicating to a slave running a newer version of MySQL, such as version 5.6, which has slave_sql_verify_checksum enabled by default meant that the last 4 bytes of events from the older master were being incorrectly interpreted as the checksum. A warning is now generated and to avoid such a situation, set slave_sql_verify_checksum=0 to disable checksums on the slave.
* Replication: When restarting MySQL with relay_log_recovery enabled to recover from a crash, if the SQL thread had never been started, the position from which to start recovery was not correctly initialized because Relay_Master_Log_File was missing. This fix ensures that in such a situation each of the relay logs, starting from the first relay log file, is searched for a rotate event from the master, which specifies where replication started from. This rotate event is then used to set the SQL thread's Relay_Master_Log_File and Relay_Log_Pos and recovery continues as normal.
* Replication: When using GTIDs for replication and with MASTER_AUTO_POSITION enabled, if a slave requested GTIDs which had been already been purged by the master, the master was sending all available GTIDs. This happened because the master reads all available binary logs and searches for a binary log which contains a GTID that is not contained in the union of gtid_executed and gtid_retrieved. If such a GTID is found, the master starts sending the information starting from that location. In a situation where the union of the slave's gtid_executed and gtid_retreived set did not contain the master's gtid_purged set, the slave would expect GTIDs which had already been purged by the master. This fix ensures that in such a situation, the slave's I/O thread is aborted with an error "Master has purged binary logs containing GTIDs that the slave requires.".
* Replication: A kernel mutex contention was being caused because mysqlbinlog was calling localtime() for every event read, which in turn called stat(/etc/localtime). This fix ensures that mysqlbinlog uses localtime_r(), which is optimized to store the read only timezone internal structure. This also means that mysqlbinlog now establishes the time zone at the beginning of processing and you can not change it during processing. This is the same behavior as MySQL server.
* Replication: The global scope for the sql_log_bin system variable has been deprecated, and this variable can now be set with session scope only. The statement SET GLOBAL SQL_LOG_BIN now produces an error. It remains possible for now to read the global value of sql_log_bin, but you should act to remove from your applications any dependencies on reading this value, as the ability to do so will be removed in a future MySQL release.
* InnoDB table checksum calculation could yield an incorrect result if the value of the innodb_checksum_algorithm system variable was modified during the operation.
* GROUP BY on a CHAR(0) NOT NULL column could lead to a server exit.
* With the validate_password plugin activated and dictionary lookups enabled, passing a user-defined variable to PASSWORD() could cause a server exit.
* Debian packages were built using the complex set of character sets, not the all set of character sets.
* mysqldump failed to report a disk-full error if the dump destination was located on an NFS mount.
* InnoDB permitted a foreign key to be created which referenced a parent table for which the user did not have sufficient privileges.
* Copying InnoDB tables containing full-text columns from Windows to Linux caused a server exit on Linux during full-text index initialization.
* On Windows, the replace utility did not work. (Bug #16581605)
* On CentOS 6, specifying a relative path name for the --socket option caused MySQL startup script failure.
* In Solaris 11.2, dtrace -V output changed from Sun D to Oracle D, causing detection of DTrace availability to fail during MySQL configuration.
* mysql_config --libs_r produces output containing link flags for libmysqlclient_r, even though that library was removed in MySQL 5.5 and replaced with a symlink to the underlying libmysqlclient library. The output now refers directly to libmysqlclient. (The implication is that it is no longer necessary to maintain the symlink for the sake of being able to use mysql_config --libs_r.)
* For statement digest calculation, the Performance Schema failed to recognize signed literal numbers as values representable by ? and created multiple digests for statements that should have had the same signature. Now all instances of unary plus and unary minus followed by a number reduce to ? in digests.
* Compilation on Windows using Visual Studio 2013 resulted in “unresolved external symbol” errors.
* OLD_PASSWORD() is deprecated, but no warning was produced when it was invoked.
* Certain queries for which subquery materialization or UNION DISTINCT was used together with a hash index on a temporary table could produce incorrect results or cause a server exit.
* The IS_FREE_LOCK() and IS_USED_LOCK() function implementations contained a race condition due to which they could access freed memory when a user lock was concurrently checked and freed. Accessing freed memory could result in an incorrect function return value or server exit.
* LOCK TABLES sometimes acquired an insufficiently strong lock for implicitly locked tables.
* The ENABLED_LOCAL_INFILE CMake option incorrectly was enabled by default.
* Use of ODBC-format date literals could produce incorrect query results.
* mysql_install_db ignored option files in the default locations.
* mysql_setpermission failed to properly quote user names in SQL statements that it generated.