RE: Re-read subscription state after lock in AlterSubscription - Mailing list pgsql-hackers

From Zhijie Hou (Fujitsu)
Subject RE: Re-read subscription state after lock in AlterSubscription
Date
Msg-id TY4PR01MB17718E4AA1A80B59B1B6FBF2D94F42@TY4PR01MB17718.jpnprd01.prod.outlook.com
Whole thread
In response to Re: Re-read subscription state after lock in AlterSubscription  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Re-read subscription state after lock in AlterSubscription
Re: Re-read subscription state after lock in AlterSubscription
List pgsql-hackers
On Friday, July 3, 2026 1:53 PM Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote:
> 
> > but given the patch's simplicity, I recommend backpatching.
> 
> That's right but that would only improve error messages. That said, looking
> closer, they are elog() ones, so "not expected" to occur so yeah backpatch
> does make sense.

+1 for backpatching, even if it's rare, the "ERROR: tuple concurrently updated"
message seems confusing to me.

> 
> That said, what about also fixing DropSubscription() like in the 0002 attached?
> (that would also produce those elog() messages in case of concurrent DROP or
> ALTER).

For the patch, I'm not sure if we must repeat the checks twice. Could we
simply move the original checks to after we take the lock? At least, the
GetSubscription() call and the password check can be moved there and old codes
can be deleted.

BTW, this may not be strictly related, but I think it's not safe to do the
ownership check before locking the subscription as well. If the subscription is
concurrently dropped, a "tuple concurrently updated" error can still occur.

(Thanks to Kuroda-San for discussing this with me off-list.)

Best Regards,
Hou zj


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: GIN amcheck leaks memory in gin_check_parent_keys_consistency
Next
From: Kirill Reshke
Date:
Subject: Re: GIN amcheck leaks memory in gin_check_parent_keys_consistency