Re: Skipping schema changes in publication

On Sat, Feb 28, 2026 at 5:27 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Feb 27, 2026 at 8:44 PM Nisha Moond <nisha.moond412@gmail.com> wrote:
> >
> > On Fri, Feb 27, 2026 at 5:01 PM Nisha Moond <nisha.moond412@gmail.com> wrote:
> > >
> > > Thanks for the patches, I am still testing the patches, but sharing a
> > > few initial review comments.
> > >
> >
> > I did few tests on v51 all patches, please find further comments -
> >
> > 1. Partition Related Behavior
> > -----------------------------
> > Setup:
> > CREATE TABLE t_part (id int) PARTITION BY RANGE (id);
> > CREATE TABLE t_part_p1 PARTITION OF t_part FOR VALUES FROM (0) TO (100);
> > CREATE TABLE t_part_p2 (id int);
> > ALTER TABLE t_part ATTACH PARTITION t_part_p2 FOR VALUES FROM (100) TO (200);
> >
> > t_part
> >   |_> t_part_p1
> >   |_> t_part_p2
> >
> > Publication:
> >   create publication pubp1 for ALL TABLES EXCEPT TABLE (t_part);
> >  -- No data from all three tables is replicated, which is expected.
> >
> > 1a) DETACH t_part_p2 from parent
> > ALTER TABLE t_part DETACH PARTITION t_part_p2;
> >
> > When t_part_p2 is detached, it becomes a standalone table and is no
> > longer part of the EXCEPT hierarchy. But, replication does not start
> > automatically. It requires REFRESH PUBLICATION on the subscriber.
> > Should we add a warning/hint during DETACH command to inform users
> > that REFRESH PUBLICATION is required?
> > It may also help to update the related documentation.
> >
>
> This is required even when a regular (non-partitioned table) is
> created to let the corresponding entry populated in
> pg_subscription_rel. See docs[1] (REFRESH PUBLICATION ..).
>

Thanks for the doc link. The expectation seems that when a user adds a
table to a publication, replication of that table will begin after
running REFRESH PUBLICATION. But, in this case, the table is added
indirectly (e.g., via a partition detach), which may not make it
obvious to userthat a refresh is required.

That said, I agree that users can handle it if they are aware of this behavior.

> > ~~
> > 2. Inherited Tables Behavior
> > Setup:
> >  CREATE TABLE t_inh (id int);
> >  CREATE TABLE t_inh_c1 (c1 int) INHERITS (t_inh);
> >  CREATE TABLE t_inh_c2 (c2 int) INHERITS (t_inh);
> > t_inh
> >   |_> t_inh_c1
> >   |_> t_inh_c2
> >
> > Publication:
> >   create publication pubi1 for ALL TABLES EXCEPT TABLE (t_inh);
> >  --All three tables are not replicated.
> >
> > 2a): Remove child from parent
> >   alter table t_inh_c1 NO INHERIT t_inh;
> >
> > \d+ t_inh shows:
> > Except Publications:
> >     "pubi1"
> > Child tables: t_inh_c2
> >
> > But the publication still shows:
> > Except tables:
> >     "public.t_inh"
> >     "public.t_inh_c1"
> >     "public.t_inh_c2"
> >
> > t_inh_c1 is no longer part of the excluded hierarchy, yet it remains
> > in the EXCEPT list and replication does not start for it.
> > This appears inconsistent and may be a bug.
> >
>
> I think after removal, it shouldn't have been shown here, so, we
> should see why it is happening. OTOH, won't replication requires user
> to perform REFRESH PUBLICATION as in the previous case?
>

Yes, this requires the user to run REFRESH PUBLICATION, but
replication still does not start in this case. The user must reset the
EXCEPT TABLE list to start replication for t_inh_c1.

--
Thanks,
Nisha