Bug #12542 SET ONE_SHOT TIME_ZONE doesn't replicate if --replicate-wild* is used
Submitted: 12 Aug 2005 7:49 Modified: 4 Sep 2005 2:59
Reporter: Alexander Keremidarski Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Replication Severity:S1 (Critical)
Version:4.1.13 OS:Any (any)
Assigned to: Lars Thalmann CPU Architecture:Any

[12 Aug 2005 7: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 10:30] Lars Thalmann
Ok to push into 4.1.
[13 Aug 2005 3: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 15: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 15: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 19:47] Timothy Smith
The patch has been pushed, and should be available in MySQL 4.1.14.
[15 Aug 2005 19:49] Timothy Smith
Sorry, ignore that last comment; the work isn't quite done yet.
[31 Aug 2005 16: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 15: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 10: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 2:59] Paul DuBois
Noted in 4.1.15 changelog.