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

From Andres Freund
Subject Re: the s_lock_stuck on perform_spin_delay
Date
Msg-id 20240105193318.vkfvs76uazgaufin@awork3.anarazel.de
Whole thread Raw
In response to Re: the s_lock_stuck on perform_spin_delay  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: the s_lock_stuck on perform_spin_delay
List pgsql-hackers
Hi,

On 2024-01-05 14:19:23 -0500, Robert Haas wrote:
> On Fri, Jan 5, 2024 at 2:11 PM Andres Freund <andres@anarazel.de> wrote:
> > I see it fairly regularly. Including finding several related bugs that lead to
> > stuck systems last year (signal handlers are a menace).
> 
> In that case, I think this proposal is dead. I can't personally
> testify to this code being a force for good, but it sounds like you
> can. So be it!

I think the proposal to make it a WARNING shouldn't go anywhere, but I think
there are several improvements that could come out of this discussion:

- assertion checks against doing dangerous stuff
- compile time help for detecting bad stuff without hitting it at runtime
- make the stuck lock message more informative, e.g. by including the length
  of time the lock was stuck for
- make sure that interrupts can't trigger the stuck lock much quicker, which
  afaict can happen today

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: the s_lock_stuck on perform_spin_delay
Next
From: Robert Haas
Date:
Subject: Re: Should the archiver process always make sure that the timeline history files exist in the archive?