On Wed, Jan 21, 2026 at 11:35 AM Dilip Kumar <[email protected]> wrote: > > Thanks for explaining this, overall I like the Approach 1, and I also > see the problem when publish via root is given in that case COPY FROM > is executed on the root and it would be hard to exclude specific > partitions. What is the behavior when root of partition tree is added > but publish via root is not true, it doesn't add any relation to > publication rel or how does it manage to not copy data from > partitions? >
So, I believe you are asking about the behavior of COPY on HEAD for the following case: CREATE PUBLICATION pub1 FOR TABLE tab_root WITH (publish_via_partition_root = false); In this scenario, pg_publication_rel contains an entry for tab_root, while pg_publication_tables contains all leaf partitions (because publish_via_partition_root = false). Consequently, pg_subscription_rel, which is derived from pg_publication_tables, also contains all corresponding leaf partitions. As a result, on HEAD, a separate tablesync worker is launched for each leaf partition, and each leaf partition is copied independently. ~~ Now, in Approach 4, when publish_via_partition_root is set to false, we propose avoiding the inclusion of leaf partitions in pg_publication_tables if their parent appears in the EXCEPT list. Given the table hierarchy described in Approach1_challenges: tab_root ├── tab_part_1 │ ├── tab_part_1_1 │ │ ├── tab_part_1_1_1 │ │ │ └── tab_part_1_1_1_1 │ │ └── tab_part_1_1_2 │ └── tab_part_1_2 │ ├── tab_part_1_2_1 │ └── tab_part_1_2_2 └── tab_part_2 If tab_part_1_1 is specified in the EXCEPT list, then pg_publication_tables will include only those leaf partitions that are not in the partition-chain of tab_part_1_1. As a result, both pg_publication_tables and pg_subscription_rel (which is built from pg_publication_tables via fetch_relation_list) will contain: tab_part_1_2_1 tab_part_1_2_2 tab_part_2 With this setup, any INSERT into tab_part_1 or tab_root that routes rows to tab_part_1_1_1_1 or tab_part_1_1_2 will not be replicated. However, rows routed to any of the three leaf partitions listed above will be replicated. I hope it answers your query. If we have to go by Approach1, then do you see any simpler way to overcome the challenges we mention for publish_via_partition_root=true case. Or any other approach altogether? thanks Shveta
