Re: Improve logical replication usability when tables lack primary keys
| От | Chao Li |
|---|---|
| Тема | Re: Improve logical replication usability when tables lack primary keys |
| Дата | |
| Msg-id | 5ABD7727-CD22-4112-A186-0E788EE78109@gmail.com обсуждение исходный текст |
| Ответ на | Re: Improve logical replication usability when tables lack primary keys (Amit Kapila <amit.kapila16@gmail.com>) |
| Список | pgsql-hackers |
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 silently failto replicate. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
В списке pgsql-hackers по дате отправления: