Re: Publication DDL can race with a concurrent UPDATE - Mailing list pgsql-hackers

From vignesh C
Subject Re: Publication DDL can race with a concurrent UPDATE
Date
Msg-id CALDaNm3RywHHvYzQszy6hTZ-GGgwe+3HvwUQsibo25wFMsRmGQ@mail.gmail.com
Whole thread
In response to Re: Publication DDL can race with a concurrent UPDATE  (Zhijie Hou <houzhijie22@gmail.com>)
Responses Re: Publication DDL can race with a concurrent UPDATE
List pgsql-hackers
On Sun, 4 Oct 2026 at 17:56, Zhijie Hou <houzhijie22@gmail.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.

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: Mario Karuza
Date:
Subject: Re: tuplesort_putdatum() does not account for tuple memory
Next
From: Sebas Mannem
Date:
Subject: Re: NOT NULL NOT ENFORCED