Re: Publication DDL can race with a concurrent UPDATE

Hi,

On Mon, Oct 5, 2026 at 3:02 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Sun, 4 Oct 2026 at 17:56, Zhijie Hou <houzhijie22(at)gmail(dot)com> wrote:
> >
> > In the worst case this could still lock a large number of tables, so the DDL
> > counts them and raises a clear error ("too many tables without a replica
> > identity in the publication") instead of a later "out of shared memory". This
> > is expected to be very rare, and since UPDATEs/DELETEs on those tables fail
> > anyway, the error should be acceptable because it hints that the publication
> > contains many tables that can't actually be published (since they lack RI).
>
> I had considered this design as well, and it was my preferred approach
> too. The main drawback is that a database or schema may contain a
> large number of tables for which the user has not configured a replica
> identity in the worst case as you pointed out. Locking all such tables
> could consume a significant number of relation locks and potentially
> exhaust the shared lock table before reaching the limit. If we are ok
> with this trade-off, I think this design is reasonable.

Right. I've seen reporters who are not comfortable with erroring out the DML,
and they'd prefer to error out the publication DDL if a table cannot be
published (lacking RI being one of the failure reasons), so I think this should
be acceptable.

Actually, I initially considered another, more invasive approach: completely
disallowing any ineligible table from being included in a published schema
(TABLES IN SCHEMA) or database (ALL TABLES). But I think the effect is too
broad — after writing a trivial patch to test it, many existing regression
tests started to fail. When you publish a schema or the whole database, there
are always some tables lacking a replica identity, and users just use ALL
TABLES for convenience since they're sure they'll only modify the valid tables,
while leaving the others unchanged or only performing inserts on them. So I'm
not sure this DDL error approach is great — maybe in the future we can
gradually move toward it, but I'm not sure it's OK to suddenly disallow all
these cases, especially for backbranches. The POC patch I shared is a kind of
hybrid approach: it starts reporting ERROR at DDL time, but only in the rare
case where too many tables are not publishable, so I personally feel it
could be more acceptable.

Best Regards,
Zhijie Hou