MySQL Bugs: #254: 3.23 master, 4.0 slave. Slave loss temp tables everytime FLUSH LOGS on master

Bug #254	3.23 master, 4.0 slave. Slave loss temp tables everytime FLUSH LOGS on master
Submitted:	8 Apr 2003 17:04	Modified:	6 Jun 2003 9:52
Reporter:	Guilhem Bichot
Status:	Closed
Category:	Server: Replication	Severity:	S2 (Serious)
Version:		OS:	Any (all)
Assigned to:	Guilhem Bichot	Target Version:

Description:
see synopsis. I have a patch, will push it tomorrow. 4.0.13 should wait for this.
This is specific to 3.23->4.0, does not occur with 4.0->4.0 or 3.23->3.23.

How to repeat:
master :
create temporary table t (a int);
flush logs;
insert into t values(10);

See error on slave 't does not exist'.

Thank you for your bug report. This issue has been fixed in the latest
development tree for that product. You can find more information about
accessing our development trees at 
    http://www.mysql.com/doc/en/Installing_source_tree.html

changeset 1.1431 in 4.0. This changeset changes something
only in the case where 3.23 master and 4.0 slave.

The patch is not 100% perfect and we need a better solution, which will require patching
3.23 and 4.0. Waiting for Monty's approval before coding (this is simple).

Still now news from Monty about this.
A few weeks ago I have "fixed" this by ignoring Start_log_event in the 4.0 slave if the
master is 3.23. This "fix" is in 4.0.13; it is not perfect as if the 3.23 master dies
brutally, slave temp tables will not be deleted until the 4.0 slave is restarted. _I_
consider we can live with it. Because it is not a very likely case (3.23 should not die
brutally very often), and just eats disk space or memory (if the table was HEAP)). But
Monty wanted something better (which would require patching 3.23, which does not solve the
problem for all installed 3.23 versions).
I don't close it as I don't know if Monty still wants me to implement something better.
But I suspend it as there's no immediate action to take now.

The first fix was to ignore Start_log_event in the 4.0.13 slave if the master is 3.23. It
was not 100% perfect as in the unlikely case of a 3.23 master's *brutal* death, slave temp
tables would not be deleted until the 4.0 slave was restarted.
I have now made a change (which will be in 3.23.57) and another (which will be in 4.0.14)
so that 3.23 master and 4.0 slave better cooperate to fix this unlikely case. So upgrading
the slave to 4.0.13 solves the bug except in the unlikely case, and upgrading the master
to 3.23.57 and the slave to 4.0.14 (when these versions are released) will solve the bug
in all cases.