Kristian Nielsen added a comment - 2024-11-29 09:16 Hm, this seems tricky. The problem seems much bigger than just RENAME. Anytime a temporary table is binlogged (in mixed/statement mode) that conflicts with the name of a global table (or even a temporary table in another concurrent connection), there will be ambiguity in mysqlbinlog | mysql about which table is referred to. Eg: --source include/have_binlog_format_mixed.inc   --let $datadir= `select @@datadir` RESET MASTER;   connect (con1,localhost,root,,); CREATE TEMPORARY TABLE t1 (a INT PRIMARY KEY); INSERT INTO t1 VALUES (1);   --connection default CREATE TABLE t1 (a INT PRIMARY KEY); INSERT INTO t1 VALUES (2);   --connection con1 INSERT INTO t1 VALUES (3); SELECT * FROM t1 ORDER BY a;   --connection default INSERT INTO t1 VALUES (4); SELECT * FROM t1 ORDER BY a;   --disconnect con1   FLUSH BINARY LOGS; DROP TABLE t1;   --exec $MYSQL_BINLOG $datadir/master-bin.000001 | $MYSQL test SELECT * FROM t1 ORDER BY a;   DROP TABLE t1; Here applying the binlog with mysqlbinlog | mysql leaves the table empty, because all rows go to the temporary table (which is discarded when mysql disconnects). I don't remember exactly how replication deals with this problem, I think it uses the thread id in the binlogged query (@@pseudo_thread_id?) to distinguish between different temporary tables with the same name. I urge whoever ends up fixing this bug to use extreme caution and not to rush it unnecessarily. I don't remember a case when a change around temporary tables replication hadn't broken something, it's probably the most error-prone replication-related area there is. Indeed. Like, we could try to rewrite all references to temporary table names in binlogged queries to some unique name containing the thread id maybe. That seems tremendously hard to get right without breaking anything. A loose idea that might be feasible is to implement some special mode (through some internal system variable maybe?) that makes temporary table name resolution do some magic so that @@pseudo_thread_id can be used to select between different temporary tables with the same name in the same client connection, that mysqlbinlog can then use in its output. But I'm still sceptical, replication of temporary tables in statement mode is a huge can of worms, and unlikely to ever become 100% robust, much less in mysqlbinlog | mysql . Maybe the best way forward is to make the change (in a non-GA version) that in MIXED mode, all use of temporary tables cause a switch to ROW mode, avoiding binlogging any temporary table names at all. This would be default, though we could provide some @@tmptable_unsafe_for_stmt_binlogging or whatever setting to enable the old backwards-compatible behaviour. This would fix a lot of problems with temporary tables in one go. But this is a task with larger scope than this bug. Maybe reasonable to document it as a restriction for mysqlbinlog | mysql that temporary table names used in STATEMENT or MIXED mode need to be globally unique. Though this is a somewhat severe restriction, still better to document it at least. Hope this helps, - Kristian.