Re: the s_lock_stuck on perform_spin_delay - Mailing list pgsql-hackers

From Robert Haas
Subject Re: the s_lock_stuck on perform_spin_delay
Date
Msg-id CA+Tgmoa4qJ4xVZi-ez0ZL-5KUT2cMiDs5eiHOG3UUBYgN33hoQ@mail.gmail.com
Whole thread Raw
In response to Re: the s_lock_stuck on perform_spin_delay  (Andy Fan <zhihuifan1213@163.com>)
Responses Re: the s_lock_stuck on perform_spin_delay
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: XLog size reductions: smaller XLRec block header for PG17
Next
From: Andy Fan
Date:
Subject: Re: the s_lock_stuck on perform_spin_delay