Re: 024_add_drop_pub.pl might fail due to deadlock

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: 024_add_drop_pub.pl might fail due to deadlock
Дата
Msg-id CAA4eK1Lqj1UdjrrZdAQ9WQ=yUJSHDn_YdAZjXtEYMDWqCwXdGw@mail.gmail.com
обсуждение исходный текст
Ответ на RE: 024_add_drop_pub.pl might fail due to deadlock  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Ответы Re: 024_add_drop_pub.pl might fail due to deadlock
Список pgsql-hackers
On Tue, Jul 29, 2025 at 7:23 AM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> > Thanks for your review Kuroda-san, I have changed the logic to not use
> > already_locked and instead check if the locks are taken inside
> > UpdateSubscriptionRelState itself. I've tested this and this works
> > fine. If this logic is acceptable to the reviewers I can update the
> > other patches also in a similar way.
>
> Thanks for updates.
> However, I found that functions like LockHeldByMe(), CheckRelationOidLockedByMe()
> and LWLockHeldByMe() have been used only for the debug build. Functions like
> ProcArraySetReplicationSlotXmin() and MarkAsPrepared() can remove the flag from
> the argument but they are retained till now.
> Based on that, I suggest adding new argument (or add new Ex function for bank branches)
> and do the assertion check when the assertion is enabled in this build. Thought?
>

Yes, that makes sense to me. For HEAD and PG18, we can still add a new
argument to the API. For other bank branches, it is better to use a
new Ex function as suggested by Kuroda-San.

--
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления: