Bug#22877 replication character sets get out of

sync using replicate-wild-ignore-table
Problem: changes in character set variables
before an action on an replication-ignored table
makes slave to forget new variable values.
Fix: initialize one_shot variables only when
4.1 -> 5.x replication is running.


mysql-test/r/rpl_ignore_table.result:
  Adding test case
mysql-test/t/rpl_ignore_table-slave.opt:
  Don't replicate tables with names starting with "tmptbl"
mysql-test/t/rpl_ignore_table.test:
  Adding test case
sql/sql_parse.cc:
  Reset one_shot variables only if we do 4.1->5.x replication.
  In other cases we cannot do that: resetting thd->variables out of sync with
  st_relay_log_info::cached_charset, which makes
  st_relay_log_info::cached_charset_compare() not to notice
  character set related variables changes afterwards.

1 files changed, 17 insertions, 1 deletions

diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc
index 18d048df393..ede21011bcd 100644
--- a/sql/sql_parse.cc
+++ b/sql/sql_parse.cc
@@ -2480,7 +2480,23 @@ mysql_execute_command(THD *thd)
     {
       /* we warn the slave SQL thread */
       my_message(ER_SLAVE_IGNORED_TABLE, ER(ER_SLAVE_IGNORED_TABLE), MYF(0));
-      reset_one_shot_variables(thd);
+      if (thd->one_shot_set)
+      {
+        /*
+          It's ok to check thd->one_shot_set here:
+
+          The charsets in a MySQL 5.0 slave can change by both a binlogged
+          SET ONE_SHOT statement and the event-internal charset setting, 
+          and these two ways to change charsets do not seems to work
+          together.
+
+          At least there seems to be problems in the rli cache for
+          charsets if we are using ONE_SHOT.  Note that this is normally no
+          problem because either the >= 5.0 slave reads a 4.1 binlog (with
+          ONE_SHOT) *or* or 5.0 binlog (without ONE_SHOT) but never both."
+        */
+        reset_one_shot_variables(thd);
+      }
       DBUG_RETURN(0);
     }
   }