From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>, Christophe Pettus <xof(at)thebuild(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | Re: "stuck spinlock" |
Date: | 2013-12-13 17:34:02 |
Message-ID: | 20131213173402.GQ29402@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-12-13 12:19:56 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2013-12-13 17:51:50 | Re: Extension Templates S03E11 |
Previous Message | Tom Lane | 2013-12-13 17:28:56 | Re: "stuck spinlock" |