Re: Publication of same parent table with ONLY-ness mismatch should error

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Takeshi Ideriha <iderihatakeshi(at)gmail(dot)com>
Cc: shveta malik <shveta(dot)malik(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Publication of same parent table with ONLY-ness mismatch should error
Date: 2026-10-19 06:20:19
Message-ID: CAHut+PvFVNXromp7JTs6=z8Zi=1NdQyZqc7tXXAXh2W32b3TGg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 15, 2026 at 5:51 PM Takeshi Ideriha
<iderihatakeshi(at)gmail(dot)com> wrote:
>
> Hi all
>
> >On 2026/08/28 13:54, shveta malik wrote:
> >> On Fri, Aug 28, 2026 at 9:04 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >>
> >> Hi.
> >>
> >> While reviewing another thread, I had cause to enumerate and try many
> >> dozens of CREATE PUBLICATION clause combinations. I found one
> >> combination that gave an unexpected result. IMO this a bug:
> >>
> >> CREATE PUBLICATION ... FOR TABLE s1.parent, TABLE ONLY s1.parent;
> >> -- No error? First wins. Behaves like FOR TABLE
> >>
> >> CREATE PUBLICATION ... FOR TABLE ONLY s1.parent, TABLE s1.parent;
> >> -- No error? First wins. Behaves like FOR TABLE ONLY
>
> I also think this is a bug and should become an error. Specifying both
> TABLE and TABLE ONLY does not make much sense.
>
>
> > I also feel that it should be an error scenario. Let's see what others
> > have to say here.
> >
> > While validating the patch, I figured out that this simple scenario,
> > even without inheritance created, also triggers the error:
> >
> > postgres=# create table tab1(i int);
> > CREATE TABLE
> > postgres=# create publication pub1 for table only tab1, tab1;
> > ERROR: conflicting ONLY specifications for table "tab1"
> >
> > I see that 't->relation->inh' is true for anything which does not have
> > 'ONLY' specified with it. It makes sense, too. Even though tab1
> > doesn't have any descendants yet, it may have them in the future, and
> > then this publication can break silently. So, it's better to reject
> > such a publication at creation time, even for tables like tab1.
>
> For a plain table with no child tables, I also feel it make sense to
> make this error. It seems to me a publication table is registered in
> pg_publication_rel based on the definition when CREATE PUBLICATION is
> executed. So, even if the plain table gets a child table in future, it
> would not affect the publication definition. Having said that, this
> should become an error.
>
> The fix and test code look good to me. I also noticed that you improved
> the doc explanation regarding the relationship between ONLY clause and
> partitioned table. How about splitting this doc patch to a separate
> patch and thread? The doc fix seems good to me but it's not directly
> related to the main issue in this thread. By separating the thread, I
> guess it would get more attention and be easier to commit.

Hi Takeshi-San.

Thanks for giving feedback on this patch.

Bugfix:
I found a scenario that was not being handled correctly -- i.e. when
implicitly inherited children were also explicitly mentioned.
Fixed and added a test case.

Docs patch:
The docs part is an independent improvement, so I'll move it to a
separate thread as suggested.

~

PSA patch v2

======
Kind Regards,
Peter Smith.
Fujitsu Australia

Attachment Content-Type Size
v2-0001-Error-if-same-table-has-ONLY-mismatch.patch application/octet-stream 11.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2026-10-19 06:51:36 Re: Fix stale allocChunkLimit when recycling AllocSet
Previous Message Chao Li 2026-10-19 06:03:54 Re: Fix stale allocChunkLimit when recycling AllocSet