Re: Warn on missing replica identity in CREATE/ALTER PUBLICATION

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: 南拓弥 <minamitakuya(at)lifull(dot)com>
Cc: shveta malik <shveta(dot)malik(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Warn on missing replica identity in CREATE/ALTER PUBLICATION
Date: 2026-04-23 06:50:22
Message-ID: 35B6A159-C2EF-4346-9394-7CB3E168B1A5@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Apr 23, 2026, at 13:46, 南拓弥 <minamitakuya(at)lifull(dot)com> wrote:
>
> # Reply draft v2 to Shveta
>
> ---
>
> Hi Shveta,
>
> Thanks for pointing out that thread. I've read through it carefully.
>
> I believe the two proposals address different aspects of the same
> problem:
>
> - The fallback RI approach changes runtime behavior so that tables
> without a primary key can still replicate UPDATE/DELETE.
> - This proposal simply warns at DDL time that a publication contains
> tables whose replica identity will cause UPDATE/DELETE to fail at
> replication time.
>
> A WARNING at publication creation time is useful regardless of whether
> a fallback mechanism exists, because:
>
> - If a table has REPLICA IDENTITY DEFAULT with no primary key, it
> silently falls back to NOTHING. Combining that with a publication
> that publishes updates/deletes is guaranteed to fail at runtime.
> A WARNING at DDL time closes this gap.
> - Even users who explicitly set REPLICA IDENTITY NOTHING and add the
> table to an update/delete publication would benefit from a reminder,
> since that combination cannot succeed.
> - The WARNING does not change any existing behavior — it only makes
> the misconfiguration visible earlier.
>
> Notably, Euler mentioned in that thread [1] that he would "suggest a
> way to disallow or add a warning message while creating the
> publication or adding new tables", which is exactly what this proposal
> does.
>
> That said, I see the two proposals as complementary. Should I continue
> this as a separate thread, or would it be better to join the existing
> discussion?
>
> I have a working patch covering all publication paths (FOR TABLE,
> FOR TABLES IN SCHEMA, FOR ALL TABLES, ALTER PUBLICATION). Happy to
> post it either way.
>
> [1] https://www.postgresql.org/message-id/a9da608f-24be-4213-a712-8592852d37f1%40app.fastmail.com
>

You are very welcome to join the thread, as the initiator of that thread.

I am not personally against your idea of adding such a warning message, but I think it would be better to consider the two features together as a whole solution from a system perspective.

In any case, new features will have to wait for v20 until July, so we still have time for more discussion and deeper consideration.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message SATYANARAYANA NARLAPURAM 2026-04-23 06:53:45 [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph
Previous Message Ashutosh Bapat 2026-04-23 06:48:55 Re: [Patch]Add Graph* node support to expression_tree_mutator