RE: Publication DDL can race with a concurrent UPDATE

On Monday, September 7, 2026 8:56 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> The underlying issue appears to be that publication DDL naming a table takes
> ShareUpdateExclusiveLock, which does not conflict with the
> RowExclusiveLock held by a concurrent UPDATE. This allows the publication
> definition to change while the UPDATE is in progress: the UPDATE uses the old
> definition when checking the operation and generating WAL, while logical
> decoding uses the new definition.

Thanks for reporting the issue.

>
> There may be other variations of this race ex: adding column list, but the
> underlying problem is the same: an UPDATE can proceed based on stale
> publication information and produce a logical replication change that is
> rejected only later on the subscriber.
>
> I fixed the issue by changing the lock taken by publication DDL from
> ShareUpdateExclusiveLock to ShareRowExclusiveLock. This makes the DDL
> conflict with the RowExclusiveLock held by concurrent data-modifying
> statements, preventing the publication definition from changing while the
> UPDATE is in progress.

I think this fix is not sufficient, as it does not address the ALTER PUBLICATION
SET (options) cases, where the publication action can also be altered
concurrently with DMLs, IIUC. The publication data in the relcache is also
affected by pubaction changes, so those should be blocked as well.

Addressing the above should be sufficient for the row filter and column list
cases. However, for the replica identity check on UPDATE and DELETE operations,
further analysis may be needed - especially for the TABLES IN SCHEMA and ALL
TABLES cases, where tables are not explicitly published.

> [1] - https://www.postgresql.org/message-
> id/CAOzEurQaGBrDu8hFw%2Bp16_uf_%2Bb94A276fYgzwUOK5X-
> bSX%2Bjg%40mail.gmail.com

Best Regards,
Zhijie Hou