Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database
От | Álvaro Herrera |
---|---|
Тема | Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database |
Дата | |
Msg-id | 202508041250.6qjjfgnqe7mi@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database
|
Список | pgsql-bugs |
On 2025-Aug-04, Dilip Kumar wrote: > I have worked on this and produced a first version of patch, let's see > what others think about this idea. It would have been better if we > could use SysCache for rechecking the subscription, but since we are > not connected to the database in the launcher we can not use the > SysCache, at least that's what I think. I think it's reasonable to recheck after locking. There's a comment in DropSubscription that says we get AEL, which is no longer true. In is_subscription_exists() you should use the index on OID instead of seqscanning the catalog without a scankey; also I think the name ought to be "does" rather than "is". I think it's really odd that that function opens and closes a transaction; sounds to me that something like that really belongs in the caller (frankly the same is true with the other function that your comment references). Why isn't systable_beginscan being used to scan the catalog? I think with this coding, the resource owner for this new lock is NULL. Is this really a good approach? Maybe there should be a resowner here. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "Always assume the user will do much worse than the stupidest thing you can imagine." (Julien PUYDT)
В списке pgsql-bugs по дате отправления: