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 15:04	Modified:	6 Jun 2003 7:52
Reporter:	Guilhem Bichot	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S2 (Serious)
Version:		OS:	Any (all)
Assigned to:	Guilhem Bichot	CPU Architecture:	Any

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.