funloop

[jw1u1]

Partitions: csi.note_120_p20250301 FOR VALUES FROM ('2025-03-01 00:00:00') TO ('2025-04-01 00:00:00'),
            csi.note_120_p20250401 FOR VALUES FROM ('2025-04-01 00:00:00') TO ('2025-05-01 00:00:00'),
            csi.note_120_p20250501 FOR VALUES FROM ('2025-05-01 00:00:00') TO ('2025-06-01 00:00:00'),
            csi.note_120_p20250601 FOR VALUES FROM ('2025-06-01 00:00:00') TO ('2025-07-01 00:00:00'),
            csi.note_120_p20250201 DEFAULT

csi=# select count(*) from csi.note_120_p20250201;
 count 
-------
     3

partition_data_proc endlessly moves 3 rows:

csi=> call partman.partition_data_proc('csi.note_120');
NOTICE:  Loop: 1, Rows moved: 3
NOTICE:  Loop: 2, Rows moved: 3
NOTICE:  Loop: 3, Rows moved: 3
NOTICE:  Loop: 4, Rows moved: 3
NOTICE:  Loop: 5, Rows moved: 3

[keithf4]

Each loop should be moving the equivalent amount of data that would go into a single child table. Going by your count statement, it looks like you have 3 rows in one child table, so that would line up so far.

[jw1u1]

Yes, 3 Rows in csi.note_120_p20250201, which is the default table and these 3 rows are endlessly moved to the same table.
I'd expected an error message, that the destination Table note_120_p20250201 already exists and cannot be created.

[jw1u1]

according to the partition boundaries, there isn't any destination table for those rows.

[keithf4]

If you made csi.note_120_p20250201 the default table, then yes this is going to be stuck in an endless loop because the default action of partition_data_proc is to move data out of the default table. pg_partman tries to make the appropriate table for that row, but it already exists, so it skips that. Skipping silently when the table already exists is intentional so that when you move data out of the default it makes the child table if necessary or just uses the existing one without complaining.

Do not make a child table that would match the name of target data the default. You do not want data to exist in the default long term otherwise it can cause performance issues when new child tables are created. pg_partman makes a table with the _default suffix as the default.