On Thu, 10 Sept 2026 at 15:11, Hayato Kuroda (Fujitsu) <[email protected]> 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
v2-0001-Fix-ALTER-PUBLICATION-race-with-concurrent-SET-AL.patch
Description: Binary data
