Bug #12542 SET ONE_SHOT TIME_ZONE doesn't replicate if --replicate-wild* is used
Submitted: 12 Aug 2005 9:49 Modified: 4 Sep 2005 4:59
Reporter: Alexander Keremidarski
Status: Closed
Category:Server: Replication Severity:S1 (Critical)
Version:4.1.13 OS:Any (any)
Assigned to: Lars Thalmann Target Version:

[12 Aug 2005 9:49] Alexander Keremidarski
Description:
When any replicate-wild-* option is used the Slave ignores SET ONE_SHOT TIME_ZONE
statements as belonging to a non-replicated table.

How to repeat:
Start slave with 
replicate-wild-ignore=mysql.* 

on Master:

USE test;
CREATE TABLE t (ts TIMESTAMP);
SET ONE_SHOT TIME_ZONE='GMT';
-- use any timezone different than server default

INSERT INTO t VALUES('2005-08-12 00:00:00');
SET ONE_SHOT TIME_ZONE='GMT';
SELECT * FROM t;
+---------------------+
| ts                  |
+---------------------+
| 2005-08-12 00:00:00 |
+---------------------+
1 row in set (0.00 sec)

On Slave:

USE test;
SET ONE_SHOT TIME_ZONE='GMT';
SELECT * FROM t;
+---------------------+
| ts                  |
+---------------------+
| 2005-08-11 21:00:00 |
+---------------------+

The difference in hours depends on Slave default timezone.

Suggested fix:
===== sql_parse.cc 1.458 vs edited =====
--- 1.458/sql/sql_parse.cc      2005-08-10 03:35:31 +12:00
+++ edited/sql_parse.cc 2005-08-12 17:45:19 +12:00
@@ -1975,11 +1975,16 @@
     /*
       Skip if we are in the slave thread, some table rules have been
       given and the table list says the query should not be replicated.
-      Exception is DROP TEMPORARY TABLE IF EXISTS: we always execute it
-      (otherwise we have stale files on slave caused by exclusion of one tmp
-      table).
+
+      Exceptions are:
+
+      - SET: we always execute it (e.g., SET ONE_SHOT TIME_ZONE = 'XYZ')
+
+      - DROP TEMPORARY TABLE IF EXISTS: we always execute it (otherwise we
+        have stale files on slave caused by exclusion of one tmp table).
     */
-    if (!(lex->sql_command == SQLCOM_DROP_TABLE &&
+    if (lex->sql_command != SQLCOM_SET_OPTION &&
+        !(lex->sql_command == SQLCOM_DROP_TABLE &&
           lex->drop_temporary && lex->drop_if_exists) &&
         all_tables_not_ok(thd,tables))
     {
[12 Aug 2005 12:30] Lars Thalmann
Ok to push into 4.1.
[13 Aug 2005 5:08] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/28244
[15 Aug 2005 17:18] Lars Thalmann
The previous patch was not ok (it can cause replication to 
fail if slave and master are differently configured).
[15 Aug 2005 17:53] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/28284
[15 Aug 2005 21:47] Timothy Smith
The patch has been pushed, and should be available in MySQL 4.1.14.
[15 Aug 2005 21:49] Timothy Smith
Sorry, ignore that last comment; the work isn't quite done yet.
[31 Aug 2005 18:09] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/29114
[1 Sep 2005 17:58] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/29187
[2 Sep 2005 12:38] Lars Thalmann
Patch has been pushed.

It will be present in MySQL 4.1.15 and 5.0.13.  (Actually the bug does not exist in 5.0,
but the patch here makes it possible to replicate from a 4.1 master to a 5.0 slave.)
[4 Sep 2005 4:59] Paul DuBois
Noted in 4.1.15 changelog.