Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL), 10.4(EOL)
-
None
Description
--source include/have_partition.inc
|
--source include/have_binlog_format_mixed.inc
|
--source include/master-slave.inc
|
|
CREATE TEMPORARY TABLE t1 (a INT NOT NULL); |
--error ER_NO_SUCH_TABLE
|
LOAD DATA INFILE 'x' INTO TABLE x; |
--error ER_PARTITION_NO_TEMPORARY
|
CREATE OR REPLACE TEMPORARY TABLE t1 (x INT) PARTITION BY HASH(x); |
CREATE TABLE t1 (b INT); |
INSERT INTO t1 VALUES (NULL); |
|
--sync_slave_with_master
|
|
# Cleanup
|
--connection master
|
DROP TABLE t1; |
--source include/rpl_end.inc |
10.4 3568427d |
Last_Errno 1048
|
Last_Error Error 'Column 'a' cannot be null' on query. Default database: 'test'. Query: 'INSERT INTO t1 VALUES (NULL)'
|
The problem starts when CREATE OR REPLACE TEMPORARY TABLE doesn't get written to the binary log. Somehow, the previous failure affects it. So, the slave still has the temporary table with a INT NOT NULL, while the master has the table with b INT [NULL], hence the failure.
Partitioning doesn't play important role here, there are other limitations on temporary tables which cause the same effect, e.g. ROW_FORMAT=COMPRESSED with InnoDB.
More variations of further replication abort (obvious, but mentioning them helps to find the existing bug report):
Same test case, with ALTER TABLE t1 PARTITION BY HASH(b); instead of INSERT...:
Last_SQL_Errno 1562
Last_SQL_Error Error 'Cannot create temporary table with partitions' on query. Default database: 'test'. Query: 'ALTER TABLE t1 PARTITION BY HASH(b)'
or, with ALTER TABLE t1 ADD SYSTEM VERSIONING;:
Last_SQL_Errno 4137
Last_SQL_Error Error 'TEMPORARY tables do not support system versioning' on query. Default database: 'test'. Query: 'ALTER TABLE t1 ADD SYSTEM VERSIONING'