Re: Skipping schema changes in publication

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

I have prepared a patch for Approach-3. We are also checking the
feasibility of other approaches.

Thanks,
Shlok Kyal