schemastore: partition DDLs do not update TableInfo for surviving partitions

[lidezhu]

What did you do?

For a partitioned table, each physical partition has its own versionedTableInfoStore, while all partitions share the logical table’s TableInfo.

After ADD PARTITION, DROP PARTITION, REORGANIZE PARTITION, or TRUNCATE PARTITION, the logical TableInfo may change even for partitions whose physical IDs remain unchanged. In particular, TiDB updates TableInfo.UpdateTS for ADD, DROP, and REORGANIZE PARTITION.

However, SchemaStore currently applies these DDLs only to newly created or removed partition IDs:

• The live apply path iterates only over created or dropped IDs.
• The history replay extractor returns a new TableInfo only for created IDs and marks only dropped IDs as deleted.
• Surviving partition IDs receive no new TableInfo version.

Example

Assume a partitioned table has the following physical partitions:

Before ADD PARTITION:

p1 = 201
p2 = 202
TableInfo.UpdateTS = 1000

After adding p3:

ALTER TABLE t ADD PARTITION (
    PARTITION p3 VALUES LESS THAN (300)
);

The resulting logical TableInfo is:

p1 = 201
p2 = 202
p3 = 203
TableInfo.UpdateTS = 2000

Expected SchemaStore state:

GetTableInfo(201, ddlTs) -> UpdateTS 2000
GetTableInfo(202, ddlTs) -> UpdateTS 2000
GetTableInfo(203, ddlTs) -> UpdateTS 2000

Actual state:

GetTableInfo(201, ddlTs) -> UpdateTS 1000
GetTableInfo(202, ddlTs) -> UpdateTS 1000
GetTableInfo(203, ddlTs) -> UpdateTS 2000

The same issue occurs for surviving partitions after DROP, REORGANIZE, and TRUNCATE PARTITION.

What did you expect to see?

The affected partition sets should be handled as follows:

• ADD PARTITION

  • Apply the new TableInfo to every partition in the post-DDL partition set.

• DROP PARTITION

  • Mark removed partition IDs as deleted.
  • Apply the new TableInfo to every surviving partition.

• REORGANIZE PARTITION

  • Mark replaced partition IDs as deleted.
  • Apply the new TableInfo to every partition in the post-DDL partition set, including surviving and newly created partitions.

• TRUNCATE PARTITION

  • Mark replaced partition IDs as deleted.
  • Apply the resulting TableInfo to surviving and newly created partitions.

The live apply and history replay paths must use equivalent affected-partition semantics.

What did you see instead?

As described above

Versions of the cluster

Upstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):

(paste TiDB cluster version here)

Upstream TiKV version (execute tikv-server --version):

(paste TiKV version here)

TiCDC version (execute cdc version):

(paste TiCDC version here)