Re: [PATCH] Skip unpublishable child tables when adding parent to publication

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 <amit(dot)kapila16(at)gmail(dot)com> wrote:

> On Tue, Dec 16, 2025 at 9:21 AM Zhijie Hou (Fujitsu)
> <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> >
> > On Tuesday, December 16, 2025 7:28 AM Euler Taveira <euler(at)eulerto(dot)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.
>