On Wed, Jan 21, 2026 at 4:57 PM shveta malik <[email protected]> wrote: > > 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 for the explanation, that clears it up. I agree that Approach 3 is the right path forward. And it makes sense to extend this with Approach 4. Logically, I think it's reasonable to say that if a user chooses to partition via the root, they are treating the entire partition tree as a single entity. Therefore, it makes sense to disallow the exclusion of individual child partitions in that context. -- Regards, Dilip Kumar Google
