Re: the s_lock_stuck on perform_spin_delay

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: the s_lock_stuck on perform_spin_delay
Дата
Msg-id CA+Tgmoa4qJ4xVZi-ez0ZL-5KUT2cMiDs5eiHOG3UUBYgN33hoQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: the s_lock_stuck on perform_spin_delay  (Andy Fan <zhihuifan1213@163.com>)
Ответы Re: the s_lock_stuck on perform_spin_delay  (Andy Fan <zhihuifan1213@163.com>)
Список pgsql-hackers
On Mon, Jan 22, 2024 at 12:13 PM Andy Fan <zhihuifan1213@163.com> wrote:
> > On Mon, Jan 22, 2024 at 11:58 AM Andy Fan <zhihuifan1213@163.com> wrote:
> >> I get your point! Acquiring an already held spinlock in quickdie is
> >> unlikely to happen, but since our existing infrastructure can handle it,
> >> then there is no reason to bypass it.
> >
> > No, the existing infrastructure cannot handle that at all.
>
> Actually I mean we can handle it without 0003. am I still wrong?
> Without the 0003, if we acquiring the spin lock which is held by
> ourself already. VerifyNoSpinLocksHeld in SpinLockAcquire should catch
> it.

But that's only going to run in assert-only builds. The whole point of
the patch set is to tell developers that there are bugs in the code
that need fixing, not to catch problems that actually occur in
production.

--
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: XLog size reductions: smaller XLRec block header for PG17
Следующее
От: Andy Fan
Дата:
Сообщение: Re: the s_lock_stuck on perform_spin_delay