Re: Review items for EXCEPT TABLE publication

On Thu, 10 Sept 2026 at 15:11, Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> Dear Vignesh,
>
> > I ran claude to identify issues related to the EXCEPT TABLE
> > publication changes.
>
> Very nice. I think this should be part of the community's routine.
>
> > Finding #1: ALTER PUBLICATION race
> > Finding #2: ALTER PUBLICATION validates against pre-lock state
>
> To confirm, why can't we acquire the lock at the beginning of AlterPublication()
> and re-check the publication state? For now AlterPublicationOptions() acquires
> the AccessShareLock only if the row filter and column list may be specified, but
> it could cause elog(ERROR, "tuple concurrently updated") error. It cannot be
> translated thus may be surprising. Instead, can we obtain AccessExclusive
> (or ShareUpdateExclusiveLock, which can block each other) at the beginning to
> block concurrent operations?

Thanks kuroda-san. I have addressed this in the v2 version patch
attached, however I did not change the lock mode and used the existing
AccessShareLock mode itself as I felt that should suffice. This
approach also addresses Chao's comments from [1].
[1] - https://www.postgresql.org/message-id/23BC758C-7DBC-4270-9232-2CC09C3679FB%40gmail.com

Regards,
Vignesh