Log Message:
Changes 5.6.19:
Functionality Added or Changed

The obsolete and unmaintained charset2html utility has been removed from MySQL \ 
distributions.

The mysqlbug, mysql_waitpid, and mysql_zap utilities have been deprecated and \ 
will be removed in MySQL 5.7.

Bugs Fixed

InnoDB: After upgrading from 5.6.10 to MySQL versions up to and including MySQL \ 
5.6.18, InnoDB would attempt to rename obsolete full-text search auxiliary \ 
tables on server startup, resulting in an assertion failure.

InnoDB: For each insert, memset would be called three times to allocate memory \ 
for system fields. To reduce CPU usage, the three memset calls are now combined \ 
into a single call.

InnoDB: Enabling the InnoDB Table Monitor would result in a \ 
ib_table->stat_initialized assertion failure.

InnoDB: Setting innodb_max_dirty_pages_pct=0 would leave 1% of dirty pages \ 
unflushed. Buffer pool flushing is initiated when the percentage of dirty pages \ 
is greater innodb_max_dirty_pages_pct. The internal variables that store the \ 
innodb_max_dirty_pages_pct value and the percentage of dirty pages \ 
(buf_get_modified_ratio_pct and srv_max_buf_pool_modified_pct) were defined as \ 
unsigned integer data types, which meant that a innodb_max_dirty_pages_pct value \ 
of 0 required a dirty pages percentage of 1 or greater to initiate buffer pool \ 
flushing.

To address this problem, the buf_get_modified_ratio_pct and \ 
srv_max_buf_pool_modified_pct internal variables are redefined as double data \ 
types, which changes the range value for innodb_max_dirty_pages_pct and \ 
innodb_max_dirty_pages_pct_lwm from 0 .. 99 to 0 .. 99.99. Additionally, buffer \ 
pool flushing is now initiated when the percentage of dirty pages is \ 
“greater than or equal to” innodb_max_dirty_pages_pct.

Replication: Log rotation events could cause group_relay_log_pos to be moved \ 
forward incorrectly within a group. This meant that, when the transaction was \ 
retried, or if the SQL thread was stopped in the middle of a transaction \ 
following one or more log rotations (such that the transaction or group spanned \ 
multiple relay log files), part or all of the group was silently skipped.

This issue has been addressed by correcting a problem in the logic used to avoid \ 
touching the coordinates of the SQL thread when updating the log position as \ 
part of a relay log rotation whereby it was possible to update the SQL thread's \ 
coordinates when not using a multi-threaded slave, even in the middle of a \ 
group.

Replication: When running the server with --gtid-mode=ON, STOP SLAVE followed by \ 
START SLAVE resulted in a mismatch between the information provided by \ 
INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO and the Slave_open_temp_tables status \ 
variable: the INNODB_TEMP_TABLE_INFO table showed that no temporary tables \ 
existed, but Slave_open_temp_tables had a nonzero value.

Replication: In certain cases, the server mishandled triggers and stored \ 
procedures that tried to modify other tables when called by CREATE TABLE ... \ 
SELECT. This is now handled correctly as an error.

Replication: When used on a table employing a transactional storage engine, a \ 
failed TRUNCATE TABLE was still written to the binary log and thus replayed on \ 
the slave. This could lead to inconsistency when the master retained data that \ 
was removed on the slave.

Now in such cases TRUNCATE TABLE is logged only when it executes successfully.

Replication: The server did not always handle the auto.cnf file correctly in \ 
cases where this file's permissions were incorrect.

Replication: When the binary log was rotated due to receipt of a SIGHUP signal, \ 
the new binary log did not contain the Previous_gtid_event required for \ 
subsequent processing of that binary log's GTID events. Now when SIGHUP is \ 
received, steps are taken to insure that the server writes the necessary \ 
Previous_gtid_event to the new log before writing any GTID events to the new \ 
log.