CVS commit: pkgsrc/databases

["Adam Ciarcinski" <adam%netbsd.org@localhost>]

Module Name:    pkgsrc
Committed By:   adam
Date:           Mon Jun  2 07:30:38 UTC 2014

Modified Files:
        pkgsrc/databases/mysql56-client: Makefile Makefile.common distinfo
        pkgsrc/databases/mysql56-server: PLIST

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.


To generate a diff of this commit:
cvs rdiff -u -r1.12 -r1.13 pkgsrc/databases/mysql56-client/Makefile
cvs rdiff -u -r1.15 -r1.16 pkgsrc/databases/mysql56-client/Makefile.common
cvs rdiff -u -r1.14 -r1.15 pkgsrc/databases/mysql56-client/distinfo
cvs rdiff -u -r1.9 -r1.10 pkgsrc/databases/mysql56-server/PLIST

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.