Re: "stuck spinlock" - Mailing list pgsql-hackers

From Andres Freund
Subject Re: "stuck spinlock"
Date
Msg-id 20131213173402.GQ29402@awork2.anarazel.de
Whole thread Raw
In response to Re: "stuck spinlock"  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "stuck spinlock"
List pgsql-hackers
On 2013-12-13 12:19:56 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > Shouldn't the HOLD_INTERRUPTS() in handle_sig_alarm() prevent any
> > eventual ProcessInterrupts() in the timeout handlers from doing anything
> > harmful?
> 
> Sorry, I misspoke there.  The case I'm worried about is doing something
> like a wait for lock, which would unconditionally set and then reset
> ImmediateInterruptOK.

I sure hope we're not going to introduce more paths that do this, but I
am not going to bet on it...

I remember trying to understand why the deadlock detector is safe doing
as it does when I was all green and was trying to understand the HS patch
and it drove me nuts.

> BTW, I'm about to go put a HOLD_INTERRUPTS/RESUME_INTERRUPTS into
> HandleCatchupInterrupt and HandleNotifyInterrupt too, for essentially the
> same reason.

Sounds good, both already do a ProcessInterrupts() at their end, so the
holdoff shouldn't lead to absorbed interrupts.

I wonder what to do about bgworker's bgworker_die()? I don't really see
how that can be fixed without breaking the API?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "stuck spinlock"
Next
From: Jeff Davis
Date:
Subject: Re: Extension Templates S03E11