MIME-Version: 1.0
References: 
 <CAEoWx2mMorbMwjKbT4YCsjDyL3r9Mp+z0bbK57VZ+OkJTgJQVQ@mail.gmail.com>
 <CAA4eK1+UL6wVDNzkpHjA7RVLD_8AkrP2tu+RvQ2h5AUjyEe+-Q@mail.gmail.com>
 <5ABD7727-CD22-4112-A186-0E788EE78109@gmail.com>
In-Reply-To: <5ABD7727-CD22-4112-A186-0E788EE78109@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
Date: Mon, 15 Dec 2025 08:58:20 +0530
Message-ID: 
 <CAFiTN-ucvk8JOiLvjii6VXar6nYJvCQDgzp8_4v55yweUmzdzw@mail.gmail.com>
Subject: Re: Improve logical replication usability when tables lack primary
 keys
To: Chao Li <li.evan.chao@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
	Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAFiTN-ucvk8JOiLvjii6VXar6nYJvCQDgzp8_4v55yweUmzdzw%40mail.gmail.com>
Precedence: bulk

On Tue, Nov 11, 2025 at 6:11=E2=80=AFPM Chao Li <li.evan.chao@gmail.com> wr=
ote:
>
> 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=E2=80=AFPM 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 s=
ummarized as follows:
> >>
> >> - A central DB operations team maintains the main database and configu=
res logical replication for all tables.
> >> - Multiple third-party application vendors are allowed to create new t=
ables in that database.
> >> - Some of these newly created tables lack a primary key. Since logical=
 replication with `REPLICATION IDENTITY DEFAULT` requires a primary key, su=
ch tables silently fail to replicate.
> >> - The DB operations team must then spend significant effort identifyin=
g 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=E2=80=99s 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=
=E2=80=99t 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?

--=20
Regards,
Dilip Kumar
Google