Re: Skipping schema changes in publication

On Sun, Feb 8, 2026 at 9:21 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Feb 6, 2026 at 3:54 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Thu, Feb 5, 2026 at 10:59 AM Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)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?

Indeed, if the user wants ALL TABLES, but they want a row filter
applied *only* for tab1, isn't this combination probably a good way to
achieve that? e.g. "pub1: FOR ALL Tables EXCEPT (tab1) and pub2: FOR
TABLE tab1 WHERE (c == 99)".

======
Kind Regards,
Peter Smith.
Fujitsu Australia