Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6
-
None
Description
If a temporary table creation was written into binary log and then another connection did RENAME on a base table with the same name, replaying such a binlog via mysqlbinlog => client causes data discrepancy – the base table remains intact (apparently RENAME is applied to the temporary table from a wrong thread instead).
It doesn't happen in a replication setup, the slave applies RENAME correctly.
--source include/have_log_bin.inc
|
--source include/have_binlog_format_mixed.inc
|
|
|
RESET MASTER;
|
CREATE TABLE t1 (a INT); |
|
|
--connect (con1,localhost,root,,)
|
CREATE TEMPORARY TABLE t1 (b INT); |
|
|
--connection default
|
RENAME TABLE t1 TO t2; |
|
|
--disconnect con1
|
--connection default
|
|
|
--echo ######
|
--echo # Tables on the original server
|
--echo #
|
SHOW TABLES IN test; |
--echo ######
|
|
|
FLUSH BINARY LOGS; |
DROP TABLE IF EXISTS t1, t2; |
|
|
--let $datadir= `select @@datadir`
|
--exec $MYSQL_BINLOG $datadir/master-bin.000001 | $MYSQL test
|
|
|
--echo ######
|
--echo # Tables after binlog replay
|
--echo #
|
SHOW TABLES IN test; |
--echo ######
|
|
|
DROP TABLE IF EXISTS t1, t2; |
|
10.2 e788738e |
######
|
# Tables on the original server |
#
|
SHOW TABLES IN test; |
Tables_in_test
|
t2
|
######
|
######
|
# Tables after binlog replay |
#
|
SHOW TABLES IN test; |
Tables_in_test
|
t1
|
######
|
The difference started showing up long time ago in 10.0 after this commit:
commit bf2e31500c9a0a7fcdccfb724e9447347a3ab684
|
Author: Alexey Botchkov
|
Date: Mon Jul 18 11:50:08 2016 +0400
|
|
|
MDEV-8569 build_table_filename() doesn't support temporary tables.
|
|
Temporary tables support added for RENAME and ALTER TABLE.
|
However, I wouldn't go as far as calling it a regression – most likely it wouldn't work anyway, just with different symptoms/outcome.
Attachments
Issue Links
- relates to
-
-
- Open
-
-
-
- Stalled
-