Re: Skipping schema changes in publication

On Mon, Feb 9, 2026 at 6:41 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Sun, Feb 8, 2026 at 9:21 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, Feb 6, 2026 at 3:54 PM shveta malik <shveta.malik@gmail.com> wrote:
> > >
> > > On Thu, Feb 5, 2026 at 10:59 AM Shlok Kyal <shlok.kyal.oss@gmail.com> wrote:
> > > >
> > > > I have added the fix of the same in the latest v41 patch and added the
> > > > corresponding test in 101_test.pl file.
> > > > I have also merged the v40-0001 and v40-0002 patches  to form v41-0001
> > > > patch and v41-0002 has the extended tests.
> > > >
> > >
> > > Thank You for the patched Shlok. While testing I found a case where
> > > table-sync and incremental-sync are not replicating same set of
> > > tables.
> > >
> > > I have attached the test-case and results in DifferentPubViaRoot.txt
> > >
> > > The problem happens when we have a subscriber subscribing to multiple
> > > pubs with different EXCEPT and different PUBLISH_VIA_PARTITION_ROOT
> > > value. Example:
> > >
> > > CREATE PUBLICATION pub1 for ALL TABLES EXCEPT table (tab_part_1_p1,
> > > tab_part_2_p2) WITH (PUBLISH_VIA_PARTITION_ROOT=true);
> > > CREATE PUBLICATION pub2 for ALL TABLES EXCEPT table (tab_part_2) WITH
> > > (PUBLISH_VIA_PARTITION_ROOT=false);
> > >
> > > We need to decide the behaviour of such a case for Apporach1.
> > >
> >
> > It is better to disallow such combinations where combining
> > publications could lead to contradictory behavior. For example, pub1:
> > FOR ALL Tables EXCEPT (tab1) and pub2: FOR TABLE tab1. Now, combining
> > pub1 and pub2 via subscription should result in an ERROR. We have
> > similar restrictions for column lists. See section: "Warning:
> > Combining Column Lists from Multiple Publications" in docs [1]. Does
> > that sound reasonable to you?
> >
> > [1] - https://www.postgresql.org/docs/devel/logical-replication-col-lists.html
> >
>
> Hi Amit.
>
> I understand there can be some tricky scenarios where partitions are
> involved, but I was not sure why "pub1: FOR ALL Tables EXCEPT (tab1)
> and pub2: FOR TABLE tab1" is an example of contradictory behaviour.
>
> Consider if the publisher has 3 tables tab1,tab2,tab3:
> Here, "pub1: FOR ALL Tables EXCEPT (tab1)" is like a shorthand for
> saying "pub1: FOR TABLE tab2,tab3"
> So what's wrong for the subscriber to combine pub1 and pub2 in this case?
>

It is because one of the publications (pub2) indicates to include a
particular table tab1 and the other one (pub1) to exclude the same
table. And things become much more complex when the Except list
contains partitions as shown in Shveta's example. So, I think it makes
sense to keep things simple at least for the first version, we can
consider to uplift this restriction if we see some use cases from the
field.

-- 
With Regards,
Amit Kapila.