A consistent snapshot transaction, and so mariadb-dump --single-transaction, fails with ERROR 1412 after DML in another session adds SYSTEM_TIME AUTO or INTERVAL partitions

--source include/have_partition.inc

--source include/have_innodb.inc

SET timestamp= UNIX_TIMESTAMP('2026-05-02 00:00:00');

--error 0,ER_PARSE_ERROR

CREATE TABLE t1 (a INT) ENGINE=InnoDB WITH SYSTEM VERSIONING PARTITION BY SYSTEM_TIME INTERVAL 1 HOUR AUTO;

if ($mysql_errno)

{

  --skip Needs SYSTEM_TIME ... AUTO partitioning

}

INSERT INTO t1 VALUES (1);

# As mariadb-dump --single-transaction does

START TRANSACTION WITH CONSISTENT SNAPSHOT;

--connect (con1,localhost,root,,test)

SET timestamp= UNIX_TIMESTAMP('2026-05-02 05:00:00');

# The UPDATE adds history partitions

UPDATE t1 SET a= 2;

--disconnect con1

--connection default

--error 0,ER_TABLE_DEF_CHANGED

SELECT COUNT(*) FROM t1 FOR SYSTEM_TIME ALL;

if ($mysql_errno)

{

  --die A transaction with a consistent snapshot can no longer read t1 after an UPDATE in another session added history partitions

}

COMMIT;

DROP TABLE t1;

Leads to:

mysqltest: At line 26: A transaction with a consistent snapshot can no longer read t1 after an UPDATE in another session added history partitions

The SELECT fails with ERROR 1412 (HY000): Table definition has changed, please retry transaction. With INTERVAL partitioning, an INSERT that adds partitions gives the same error. With mariadb-dump --single-transaction, such an INSERT into z_int while the dump waits for a lock on another table makes the dump stop with exit code 3, in 4 of 4 runs:

mariadb-dump: Error 1412: Table definition has changed, please retry transaction when dumping table `z_int` at row: 0

A SELECT that reads only the partitions that existed before works, and an INSERT that needs no new partition stops neither the dump nor the SELECT. An explicit ALTER TABLE ... ADD PARTITION in the other session gives the same error. Optimized builds give the same result.

From the code it seems that the new partitions are new InnoDB tables, so their indexes are newer than the read view of the transaction. ha_innobase::change_active_index() then marks the index as not usable, and row_search_mvcc() returns DB_MISSING_HISTORY, which becomes HA_ERR_TABLE_DEF_CHANGED. The mariadb-dump --help text lists ALTER TABLE among the statements that no other connection should use during a --single-transaction dump. With SYSTEM_TIME ... AUTO or INTERVAL partitioning, an UPDATE or an INSERT has the same effect.