ApsaraDB RDS:What do I do if I failed to create a partitioned table by using the pg_partman extension?

Why this happens

pg_partman tracks every partitioned table it manages in an internal metadata table called part_config. This table is the extension's only source of truth: pg_partman has no awareness of a partitioned table unless a record exists in part_config.

When you drop a partitioned table using DROP TABLE directly — bypassing the extension — the record in part_config is not removed. If you then create a new partitioned table with the same name and call create_parent again, pg_partman tries to insert a duplicate entry into part_config, which violates the primary key constraint and triggers the error.

-- Create a partitioned table
CREATE TABLE part_test(a INT PRIMARY KEY,b INT) PARTITION BY RANGE (a);
SELECT create_parent(p_parent_table=>'public.part_test',p_control=>'a',p_interval=>'10',p_premake=>10);
DROP TABLE part_test;

-- Create a partitioned table with the same name
CREATE TABLE part_test(a INT PRIMARY KEY,b INT) PARTITION BY RANGE (a);
SELECT create_parent(p_parent_table=>'public.part_test',p_control=>'a',p_interval=>'10',p_premake=>10);

Solution

Use undo_partition to deregister the partitioned table from pg_partman and migrate its data before dropping the table.

1. Create a non-partitioned table to receive the migrated data.

   -- Create a non-partitioned table with the same schema
   CREATE TABLE part_test_bak(a INT PRIMARY KEY,b INT);

2. Remove the partitions and migrate data to the non-partitioned table.

   -- Remove the partitions of the partitioned parent table and migrate its data to the non-partitioned table
   SELECT undo_partition('public.part_test',p_target_table := 'public.part_test_bak');

3. Drop the parent table.

   -- Delete the parent table
   DROP TABLE part_test;

Prevent this error

To avoid metadata drift, always use undo_partition to remove partitioned tables managed by pg_partman rather than dropping them directly with DROP TABLE.

For automatic protection, configure event triggers to automatically process and update the metadata table when DDL operations are performed. This keeps the extension's metadata in sync regardless of how tables are dropped.

For upstream context on this issue, see pg_partman community issue #697.