Re: Skipping schema changes in publication

On Wed, Jan 21, 2026 at 4:57 PM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Wed, Jan 21, 2026 at 11:35 AM Dilip Kumar <dilipbalaut@gmail.com> 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