On Sat, Feb 28, 2026 at 5:27 PM Amit Kapila <[email protected]> wrote: > > On Fri, Feb 27, 2026 at 8:44 PM Nisha Moond <[email protected]> wrote: > > > > On Fri, Feb 27, 2026 at 5:01 PM Nisha Moond <[email protected]> > > 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
