| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andy Fan <zhihuifan1213(at)163(dot)com> |
| Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <tmunro(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: the s_lock_stuck on perform_spin_delay |
| Date: | 2024-01-22 17:25:14 |
| Message-ID: | CA+Tgmoa4qJ4xVZi-ez0ZL-5KUT2cMiDs5eiHOG3UUBYgN33hoQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jan 22, 2024 at 12:13 PM Andy Fan <zhihuifan1213(at)163(dot)com> wrote:
> > On Mon, Jan 22, 2024 at 11:58 AM Andy Fan <zhihuifan1213(at)163(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andy Fan | 2024-01-22 17:31:59 | Re: the s_lock_stuck on perform_spin_delay |
| Previous Message | Robert Haas | 2024-01-22 17:23:42 | Re: XLog size reductions: smaller XLRec block header for PG17 |