MIME-Version: 1.0
References: 
 <CAEoWx2mMorbMwjKbT4YCsjDyL3r9Mp+z0bbK57VZ+OkJTgJQVQ@mail.gmail.com>
In-Reply-To: 
 <CAEoWx2mMorbMwjKbT4YCsjDyL3r9Mp+z0bbK57VZ+OkJTgJQVQ@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Tue, 11 Nov 2025 16:48:54 +0530
Message-ID: 
 <CAA4eK1+UL6wVDNzkpHjA7RVLD_8AkrP2tu+RvQ2h5AUjyEe+-Q@mail.gmail.com>
Subject: Re: Improve logical replication usability when tables lack primary
 keys
To: Chao Li <li.evan.chao@gmail.com>
Cc: 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/CAA4eK1%2BUL6wVDNzkpHjA7RVLD_8AkrP2tu%2BRvQ2h5AUjyEe%2B-Q%40mail.gmail.com>
Precedence: bulk

On Mon, Nov 10, 2025 at 1:36=E2=80=AFPM Chao Li <li.evan.chao@gmail.com> wr=
ote:
>
> * BACKGROUND
>
> This requirement comes from several users operating large deployments, pa=
rticularly in HIS (Hospital Information Systems). The situation can be summ=
arized 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 tabl=
es in that database.
> - Some of these newly created tables lack a primary key. Since logical re=
plication with `REPLICATION IDENTITY DEFAULT` requires a primary key, such =
tables silently fail to replicate.
> - The DB operations team must then spend significant effort identifying t=
he 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?

--=20
With Regards,
Amit Kapila.