Hello Amit, Yes, That's my understanding as well.
> The behavior should be the same for both partition and inherited tables. I'm planning to tackle partition tables in the follow-up patch. What do you think? Thanks, Arun On Tue, 16 Dec 2025 at 15:04, Amit Kapila <[email protected]> wrote: > On Tue, Dec 16, 2025 at 9:21 AM Zhijie Hou (Fujitsu) > <[email protected]> wrote: > > > > On Tuesday, December 16, 2025 7:28 AM Euler Taveira <[email protected]> > wrote: > > > > > > On Mon, Dec 15, 2025, at 3:57 AM, Amit Kapila wrote: > > > > > > > > I think the unlogged table is afterwards silently ignored during > > > > replication. > > > > > > > > > > There is also the FOR ALL TABLES case. The manual says > > > > > > Marks the publication as one that replicates changes for all tables > in the > > > database, including tables created in the future. > > > > > > It says nothing about relation kind. This is an oversight. FOR TABLE > and FOR > > > TABLES IN SCHEMA mention about the unsupported relations. One > suggestion > > > is to > > > avoid repeating the same sentence in each clause and add it to the > command > > > description. Maybe using a <note>...</note>. > > > > > > Regarding the FOR ALL TABLES behavior, should it prohibit > creating/attaching > > > a > > > partition for an unsupported relation? Different from the FOR TABLE > clause > > > that > > > you have a specified relation, in this case you don't one. It means > you could > > > have an error for regular commands (CREATE TABLE or ALTER TABLE ... SET > > > UNLOGGED) if you simply have a publication with FOR ALL TABLES. This > > > change > > > might break routines that are working today and I think that is a bad > idea. A > > > reasonable solution is to ignore the unsupported objects. It means a > > > partitioned table that has a single unlogged table as a partition will > be > > > ignored. It changes the current behavior to have "all or nothing" > instead of > > > "some". IMO it is easier to detect an issue if the partitioned table > is empty > > > then if there is just partial data in it. > > > > > > In summary, I think we should prohibit adding a partitioned table to a > > > publication if there is any unsupported relation that is a partition > of it. The > > > FOR ALL TABLES ignores the partitioned table if there is any > unsupported > > > relation. Opinions? > > > > I thought about implementing a rule within publication DDLs to prevent > adding > > partitioned tables with unsupported partitions to a publication. > However, users > > can still create problematic partitioned tables later using commands > like ATTACH > > PARTITION, CREATE PARTITION OF, or ALTER TABLE SET UNLOGGED. These > commands are > > similar to those that you identified in the FOR ALL TABLES scenario. > This raises > > uncertainty about how we should address these commands in the FOR single > TABLE > > scenario. Should we permit these user commands but restrict only adding > > unsupported relation to publication, or should we apply restrictions > across all > > such commands? The former might lead to inconsistency with the FOR ALL > TABLES > > setting, where unsupported relations are silently ignored. > > > > Prohibiting all commands sounds too restrictive in all cases (FOR ALL > TABLES, FOR TABLE, etc.). It would be better if we can disallow > creating a publication when the user explicitly adds such a relation > in a FOR TABLE publication, otherwise raise a WARNING and don't make > it part of publication. The behavior should be the same for both > partition and inherited tables. > > -- > With Regards, > Amit Kapila. >
