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 по дате отправления: