Re: Improve logical replication usability when tables lack primary keys
| От | Chao Li |
|---|---|
| Тема | Re: Improve logical replication usability when tables lack primary keys |
| Дата | |
| Msg-id | 23A24BFF-18A7-4FE9-AAFA-13E1AA207DD0@gmail.com обсуждение исходный текст |
| Ответ на | Re: Improve logical replication usability when tables lack primary keys (Dilip Kumar <dilipbalaut@gmail.com>) |
| Ответы |
Re: Improve logical replication usability when tables lack primary keys
|
| Список | 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 по дате отправления: