Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Subject: Re: Improve logical replication usability when tables lack primary
 keys
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <CAFiTN-ucvk8JOiLvjii6VXar6nYJvCQDgzp8_4v55yweUmzdzw@mail.gmail.com>
Date: Mon, 15 Dec 2025 11:35:36 +0800
Cc: Amit Kapila <amit.kapila16@gmail.com>,
 Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <23A24BFF-18A7-4FE9-AAFA-13E1AA207DD0@gmail.com>
References: 
 <CAEoWx2mMorbMwjKbT4YCsjDyL3r9Mp+z0bbK57VZ+OkJTgJQVQ@mail.gmail.com>
 <CAA4eK1+UL6wVDNzkpHjA7RVLD_8AkrP2tu+RvQ2h5AUjyEe+-Q@mail.gmail.com>
 <5ABD7727-CD22-4112-A186-0E788EE78109@gmail.com>
 <CAFiTN-ucvk8JOiLvjii6VXar6nYJvCQDgzp8_4v55yweUmzdzw@mail.gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/23A24BFF-18A7-4FE9-AAFA-13E1AA207DD0%40gmail.com>
Precedence: bulk


> On Dec 15, 2025, at 11:28, Dilip Kumar <dilipbalaut@gmail.com> wrote:
>=20
> On Tue, Nov 11, 2025 at 6:11=E2=80=AFPM Chao Li =
<li.evan.chao@gmail.com> wrote:
>>=20
>> Hi Amit,
>>=20
>> Thanks for asking.
>>=20
>>> On Nov 11, 2025, at 19:18, Amit Kapila <amit.kapila16@gmail.com> =
wrote:
>>>=20
>>> On Mon, Nov 10, 2025 at 1:36=E2=80=AFPM Chao Li =
<li.evan.chao@gmail.com> wrote:
>>>>=20
>>>> * BACKGROUND
>>>>=20
>>>> This requirement comes from several users operating large =
deployments, particularly in HIS (Hospital Information Systems). The =
situation can be summarized as follows:
>>>>=20
>>>> - 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.
>>>>=20
>>>=20
>>> Can you share an example of how we silently fail to replicate? Won't
>>> in such cases UPDATE/DELETE will anyway raise an ERROR?
>>>=20
>>=20
>> Yes, UPDATE/DELETE will fail. That=E2=80=99s the easy case to expose =
the error. Actually my patch will allow the update/delete.
>>=20
>> However, some tables, like dictionary tables, they are important, but =
don=E2=80=99t have much update/delete, they may silently fail to =
replicate.
>=20
> 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
> --=20
> 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, attached v1 patch is a PoC =
that has implemented the logic.

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