Bug #1686 If 2 master threads with same-name temp table, slave makes bad binlog
Submitted: 28 Oct 2003 2:46 Modified: 6 Nov 2003 6:37
Reporter: Guilhem Bichot Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: Replication Severity:S1 (Critical)
Version:4.0 OS:Any (all)
Assigned to: Guilhem Bichot

[28 Oct 2003 2:46] Guilhem Bichot
This is related to http://bugs.mysql.com/?id=1240
("slave of slave breaks when STOP SLAVE was issud on parent slave and temp tables were used"), because it's a problem with the thread id which is logged into the slave's binlog. But it's not a simple duplicate; it is a more serious problem.

How to repeat:
Start replication.
Master: open connection1 and do "CREATE TEMPORARY TABLE test.t(a INT)" (leave the connection1 open), open connection2 and in connection2 do "CREATE TEMPORARY TABLE test.t(a INT)".
Then in the slave's binlog you see:

#031028 11:39:10 server id 1  log_pos 4         Query   thread_id=11    exec_time=0     error_code=0
create temporary table test.t(a int);
#031028 11:39:40 server id 1  log_pos 71        Query   thread_id=11    exec_time=0     error_code=0
create temporary table test.t(a int);

So when one uses this binlog (with mysqlbinlog|mysql) this will fail (as the temp table is created *twice* (see the same thread id: 11; 11 is the id of the slave SQL thread). And if the slave is itself the master of a 2nd slave, the 2nd will slave ("table already exists").
[29 Oct 2003 5:24] Guilhem Bichot
Proposed patch is in 
ChangeSet@1.1583, 2003-10-29 14:23:35+01:00, guilhem@mysql.com
[6 Nov 2003 6:37] Guilhem Bichot
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at

ChangeSet@1.1608.1.1, 2003-11-03 18:24:01+01:00, guilhem@mysql.com