On Sun, Mar 1, 2026 at 6:21 PM shveta malik <[email protected]> wrote: > > On Sun, Mar 1, 2026 at 5:52 PM Amit Kapila <[email protected]> wrote: > > > > On Sat, Feb 28, 2026 at 7:37 PM vignesh C <[email protected]> wrote: > > > > > > This occurs because when ONLY is not specified, the table t_inh and > > > all its descendant tables (t_inh_c1 and t_inh_c2) are added to > > > pg_publication_rel at the time the publication is created. Replication > > > then proceeds strictly based on the entries in pg_publication_rel. > > > There is no explicit parent child mapping maintained for these > > > relations in the publication catalog; each table is treated as an > > > independent entry. > > > When "ALTER TABLE t_inh_c1 NO INHERIT t_inh;" is executed later, > > > t_inh_c1 is not automatically removed from the publication. Since it > > > was added as a separate entry in pg_publication_rel, removing the > > > inheritance relationship does not affect its publication membership. > > > I'm not sure whether this is the intended design or an unintended side > > > effect. If this behavior is not expected, we can address it separately > > > and adjust the implementation accordingly. > > > > > > > So, the similar case for partitioned table works because there we add > > only root partitioned table in pg_publication_rel. I understand that > > current behaviour for inherited tables (each inherited table is > > considered separately after being added to the publication) is because > > of the existing design and should be changed separately, if required. > > I haven't checked whether it is possible to change this behavior but > > it appears that we should try to investigate and see the possibility > > of fixing it separately. > > > > IMO, we do not need any change in behaviour here. > > For inherited tables, publication membership is materialized at the > time the publication is created and is not dynamically derived from > the current inheritance hierarchy. Once inherited tables are added to > a publication, each table is treated as an independent publication > member going forward, regardless of subsequent changes to the > inheritance relationship. > This differs from partitioned tables in PostgreSQL. In the case of > partitioning, publication membership is derived dynamically from the > partition hierarchy. Partitions are not independent logical tables; > they are structural components of a single logical table. Thus > attaching or detaching a partition automatically impacts publication > behavior. IMO, this distinction between inherited and partitioned > tables is fundamental to their design, and thus should be preserved > as-is, including in the context of publications. Or let me know if my > understanding is not correct here. >
Okay, noted! My main concern is that whenever a user attaches or detaches a child table, they must manually reset the publication EXCEPT list if they want the table to be replicated. The doc under “For inherited tables...” -- “If ONLY is not specified, the table and all its descendant tables (if any) are excluded.” does not clearly state that this applies only at the time of CREATE/ALTER PUBLICATION, and that users must explicitly handle changes if the inheritance hierarchy is modified later. I am fine with updating the doc accordingly. -- Thanks, Nisha
