Work around for getting a table sync issue when super privileges are not available and not syncing between a master and a slave. This code change adds an option called "--no-bin-log-format" to tell pt-table-sync that is is okay to avoid using "SET @@binlog_format=STATEMENT" . This addresses only one of many possible places where the super privilege is needed In pt-table-sync there is original code looking like this (I intentionally did not provide diff/patch formatted changes, since these are changes to the distributed perl code): sub get_cxn { ... # Ensure statement-based replication. # http://code.google.com/p/maatkit/issues/detail?id=95 $sql = '/*!50105 SET @@binlog_format="STATEMENT"*/'; PTDEBUG && _d($dbh, $sql); $dbh->do($sql); The changed code is: # Ensure statement-based replication. # http://code.google.com/p/maatkit/issues/detail?id=95 if ( $o->get('bin-log-format') ) { $sql = '/*!50105 SET @@binlog_format="STATEMENT"*/'; PTDEBUG && _d($dbh, $sql); $dbh->do($sql); } which requires that the bin-log-format option be added to the POD section, So I added this: original: =item --[no]bin-log default: yes Log to the binary log (C). Specifying C<--no-bin-log> will C. =item --buffer-in-mysql Changed code: =item --[no]bin-log default: yes Log to the binary log (C). Specifying C<--no-bin-log> will C. =item --[no]bin-log-format default: yes Force binlog_format to STATEMENT (C). Specifying C<--no-bin-log> will prevent binlog_format modification. =item --buffer-in-mysql I'd like to understand the percona toolkit build and tests better so that I can offer suggestions for code enhancements (especially for making tools work with systems like Amazon's RDS where super privilege will never be permitted). Is there a percona toolkit developer "getting started guide" that I may have missed? I understand only Percona employees will make changes to the official code, so I my purpose is to provide helpful and working code suggestions that are easy to read, test, and consider for code change candidates.