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.