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

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [PATCH] Skip unpublishable child tables when adding parent to publication
Дата
Msg-id CAA4eK1LiH5=UMFh2ENZFx7CG6cvoN0OuGd=bsS+MTdafKeg22g@mail.gmail.com
обсуждение исходный текст
Ответ на RE: [PATCH] Skip unpublishable child tables when adding parent to publication  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Ответы Re: [PATCH] Skip unpublishable child tables when adding parent to publication
Список 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 по дате отправления: