On Fri, Jul 3, 2026 at 9:49 AM Bertrand Drouvot <[email protected]> wrote: > > Hi Kuroda-san, > > On Fri, Jul 03, 2026 at 03:13:08AM +0000, Hayato Kuroda (Fujitsu) wrote: > > Dear Bertrand, > > > > > Yeah, but I think they would produce "tuple concurrently updated" error > > > (due to > > > CatalogTupleUpdate) so that invalid information could not be used. > > > > I confirmed with PG14 that tuple concurrently updated ERROR can be raised > > when > > ALTER SUBSCRIPTION DISABLE happens concurrently: > > > > ``` > > postgres=# ALTER SUBSCRIPTION sub DISABLE ; > > ERROR: tuple concurrently updated > > ``` > > Yeah, reproducible by using a breakpoint just before acquiring the lock for > example. > > > It might be harmless but I think the correct ERROR should be reported: the > > patch > > should be backpatched. Thought? > > I'm not sure about the back patch part as it would only improve error messages > in a rare race condition (and there is no risk of invalid data being used).
Patch LGTM. IMHO we can backpatch this as it is a small change and also fixes the bug, without this fix a non-superuser executing ALTER SUBSCRIPTION could bypass the password_required=false restriction if a concurrent transaction updated that flag. However, we could argue that this is a corner case and can be skipped but given the patch's simplicity, I recommend backpatching. -- Regards, Dilip Kumar Google
