On Tue, Nov 11, 2025 at 6:11 PM Chao Li <[email protected]> wrote: > > Hi Amit, > > Thanks for asking. > > > On Nov 11, 2025, at 19:18, Amit Kapila <[email protected]> wrote: > > > > On Mon, Nov 10, 2025 at 1:36 PM Chao Li <[email protected]> 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 fail 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
