On Fri, Jul 3, 2026 at 9:09 PM Bertrand Drouvot <[email protected]> wrote: > > On Fri, Jul 03, 2026 at 03:45:34PM +0530, Amit Kapila wrote: > > But while doing this and looking closely, I'm not sure AlterPublication() does > it right. Indeed, in theory, the OID could have been re-used too (between the > time we did the name resolution and the time we lock the publication). I think > what is needed is something similar to RangeVarGetRelidExtended(), means do > the > name resolution, acl check (ownership) and lock acquisition, all in unison. >
It seems RangeVarGetRelidExtended() also doesn't do the additional invalidation handling if the caller already has an appropriate lock, see comments [1]. Apart from that also, I am not sure it is a good ideal to add this additional handling in Pub/Sub DDLs as in worst case scenario even if the OID is re-used the user will face "tuple concurrently updated" or similar ERRORs, it won't do anything wrong. So for such rare cases, it doesn't seem worth adding this additional re-checking machinery. Based on the same theory, I am thinking again whether it is worth backpatching these patches? I mean these fall into the category of improving user facing messages during Pub/Sub DDLs, so isn't it okay to just push this work in HEAD? [1]: /* * If no lock requested, we assume the caller knows what they're * doing. They should have already acquired a heavyweight lock on * this relation earlier in the processing of this same statement, so * it wouldn't be appropriate to AcceptInvalidationMessages() here, as * that might pull the rug out from under them. */ if (lockmode == NoLock) -- With Regards, Amit Kapila.
