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.

BitKeeper/etc/collapsed

@@ -3,3 +3,4 @@
 44edb86b1iE5knJ97MbliK_3lCiAXA
 44f33f3aj5KW5qweQeekY1LU0E9ZCg
 4513d8e4Af4dQWuk13sArwofRgFDQw
+4538a7b0EbDHHkWPbIwxO6ZIDdg6Dg

mysql-test/r/rpl_ignore_table.result

@@ -14,3 +14,19 @@ SELECT * FROM t4;
 a
 DROP TABLE t1;
 DROP TABLE t4;
+DROP TABLE IF EXISTS t5;
+CREATE TABLE t5 (
+word varchar(50) collate utf8_unicode_ci NOT NULL default ''
+) DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
+SET @@session.character_set_client=33,@@session.collation_connection=192;
+CREATE TEMPORARY TABLE tmptbl504451f4258$1 (id INT NOT NULL) ENGINE=MEMORY;
+INSERT INTO t5 (word)  VALUES ('TEST’');
+SELECT HEX(word) FROM t5;
+HEX(word)
+54455354E28099
+SELECT HEX(word) FROM t5;
+HEX(word)
+54455354E28099
+SELECT * FROM tmptbl504451f4258$1;
+ERROR 42S02: Table 'test.tmptbl504451f4258$1' doesn't exist
+DROP TABLE t5;

mysql-test/t/rpl_ignore_table-slave.opt

---replicate-ignore-table=test.t1 --replicate-ignore-table=test.t2 --replicate-ignore-table=test.t3
+--replicate-ignore-table=test.t1 --replicate-ignore-table=test.t2 --replicate-ignore-table=test.t3 --replicate-wild-ignore-table=%.tmptbl%

mysql-test/t/rpl_ignore_table.test

@@ -26,3 +26,26 @@ SELECT * FROM t4;
 connection master;
 DROP TABLE t1;
 DROP TABLE t4;
+
+
+#
+# bug#22877 replication character sets get out of sync
+# using replicate-wild-ignore-table
+#
+--disable_warnings
+DROP TABLE IF EXISTS t5;
+--enable_warnings
+CREATE TABLE t5 (
+ word varchar(50) collate utf8_unicode_ci NOT NULL default ''
+) DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
+SET @@session.character_set_client=33,@@session.collation_connection=192;
+CREATE TEMPORARY TABLE tmptbl504451f4258$1 (id INT NOT NULL) ENGINE=MEMORY;
+INSERT INTO t5 (word)  VALUES ('TEST’');
+SELECT HEX(word) FROM t5;
+sync_slave_with_master;
+connection slave;
+SELECT HEX(word) FROM t5;
+--error 1146
+SELECT * FROM tmptbl504451f4258$1;
+connection master;
+DROP TABLE t5;

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));
+      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);
     }
   }