Re: [PATCH] Skip unpublishable child tables when adding parent to publication - Mailing list pgsql-hackers
| From | Amit Kapila |
|---|---|
| Subject | Re: [PATCH] Skip unpublishable child tables when adding parent to publication |
| Date | |
| Msg-id | CAA4eK1LiH5=UMFh2ENZFx7CG6cvoN0OuGd=bsS+MTdafKeg22g@mail.gmail.com Whole thread Raw |
| In response to | RE: [PATCH] Skip unpublishable child tables when adding parent to publication ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
| Responses |
Re: [PATCH] Skip unpublishable child tables when adding parent to publication
|
| List | pgsql-hackers |
On Tue, Dec 16, 2025 at 9:21 AM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote: > > On Tuesday, December 16, 2025 7:28 AM Euler Taveira <euler@eulerto.com> 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.
pgsql-hackers by date: