[MDEV-16229] Replication aborts with ER_VIEW_SELECT_TMPTABLE after half-failed RENAME Created: 2018-05-21  Updated: 2018-05-24  Resolved: 2018-05-23

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Data Definition - Temporary, Replication
Affects Version/s: 10.2, 10.3
Fix Version/s: 10.0.36, 10.1.34, 10.2.16, 10.3.8

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None


 Description   

--source include/have_binlog_format_mixed.inc
--source include/master-slave.inc
 
CREATE TABLE t1 (a INT);
CREATE TEMPORARY TABLE t1 (b INT);
--error 0,ER_CANT_REOPEN_TABLE,ER_TABLE_EXISTS_ERROR
RENAME TABLE t1 TO tmp, tmp TO t1;
CREATE VIEW v AS SELECT * FROM t1;
 
--sync_slave_with_master
 
# Cleanup
--connection master
DROP VIEW v;
DROP TABLE t1;
--source include/rpl_end.inc

In the test case above, RENAME TABLE behaves differently on different versions.

  • on 5.5 it succeeds, and t1 ends up as a temporary table. Thus, the next CREATE VIEW already fails on the master, and there is no discrepancy with the slave;
  • on 10.0 and 10.1 it fails completely with ER_CANT_REOPEN_TABLE, so t1 remains being a temporary table, thus the next CREATE VIEW also fails on the master, and there is no discrepancy on the slave;
  • but on 10.2 and 10.3, it fails partially with ER_TABLE_EXISTS_ERROR – first, it renames the temporary table t1 to tmp}, and then it fails to rename {{tmp to t1, so it ends up with t1 being a base table, and the next CREATE VIEW succeeds on the master; but it doesn't write the half-failed RENAME to the binary log, so the slave still have t1 as a temporary table, and CREATE VIEW fails there with

    Last_SQL_Error	Error 'View's SELECT refers to a temporary table 't1'' on query. Default database: 'test'. Query: 'CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v` AS SELECT * FROM t1'
    

I'm not quite sure which part is a bug – maybe it's wrong that the second part of RENAME fails, as it attempts to rename tmp to a base table rather than temporary table; or maybe it should be so, but then it should be written to the binary log (with the error code). In any case, something is wrong, since it causes a replication abort.



 Comments   
Comment by Michael Widenius [ 2018-05-22 ]

Problem was that detection of temporary tables was all wrong for
RENAME TABLE.
(Temporary tables where opened by top level call to
open_temporary_tables(), which can't detect if a temporary table
was renamed to something and then reused).

Fixed by adding proper parsing of rename list to check against
the current name of a table at each rename stage.
Also change do_rename_temporary() to check against the current
state of temporary tables, not according to the state of start
of RENAME TABLE.

Comment by Michael Widenius [ 2018-05-23 ]

Testing with mtr and buildbot

Generated at Thu Feb 08 08:27:20 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.