Re: Improve logical replication usability when tables lack primary keys - Mailing list pgsql-hackers

From Chao Li
Subject Re: Improve logical replication usability when tables lack primary keys
Date
Msg-id 23A24BFF-18A7-4FE9-AAFA-13E1AA207DD0@gmail.com
Whole thread Raw
In response to Re: Improve logical replication usability when tables lack primary keys  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Improve logical replication usability when tables lack primary keys
List pgsql-hackers

> On Dec 15, 2025, at 11:28, Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Tue, Nov 11, 2025 at 6:11 PM Chao Li <li.evan.chao@gmail.com> wrote:
>>
>> Hi Amit,
>>
>> Thanks for asking.
>>
>>> On Nov 11, 2025, at 19:18, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>>
>>> On Mon, Nov 10, 2025 at 1:36 PM Chao Li <li.evan.chao@gmail.com> wrote:
>>>>
>>>> * BACKGROUND
>>>>
>>>> This requirement comes from several users operating large deployments, particularly in HIS (Hospital Information
Systems).The situation can be summarized as follows: 
>>>>
>>>> - A central DB operations team maintains the main database and configures logical replication for all tables.
>>>> - Multiple third-party application vendors are allowed to create new tables in that database.
>>>> - Some of these newly created tables lack a primary key. Since logical replication with `REPLICATION IDENTITY
DEFAULT`requires a primary key, such tables silently fail to replicate. 
>>>> - The DB operations team must then spend significant effort identifying the affected tables and correcting them
manually.
>>>>
>>>
>>> Can you share an example of how we silently fail to replicate? Won't
>>> in such cases UPDATE/DELETE will anyway raise an ERROR?
>>>
>>
>> Yes, UPDATE/DELETE will fail. That’s the easy case to expose the error. Actually my patch will allow the
update/delete.
>>
>> However, some tables, like dictionary tables, they are important, but don’t have much update/delete, they may
silentlyfail to replicate. 
>
> But other than UPDATE/DELETE for what operation we need RI, I mean
> INSERT would work without any RI and UPDATE/DELETE will fail on the
> publisher itself without setting RI, so can you explain the exact case
> where it will silently fail to replicate?
>
> --
> Regards,
> Dilip Kumar
> Google

Hi Dilip,

Thanks for asking. When fallback to FULL, UPDATE/DELETE will be allowed in the publisher side. In my first email,
attachedv1 patch is a PoC that has implemented the logic. 

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







pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Improve logical replication usability when tables lack primary keys
Next
From: Michael Paquier
Date:
Subject: Re: Fix memory leak in gist_page_items() of pageinspect