| 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 |
| 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 |