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

From Andres Freund
Subject Re: "stuck spinlock"
Date
Msg-id 20131213163912.GN29402@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 11:26:44 -0500, Tom Lane wrote:
> On closer inspection, I'm thinking that actually it'd be a good idea if
> handle_sig_alarm did what we do in, for example, HandleCatchupInterrupt:
> it should save, clear, and restore ImmediateInterruptOK, so as to make
> the world safe for timeout handlers to do things that might include a
> CHECK_FOR_INTERRUPTS.

Shouldn't the HOLD_INTERRUPTS() in handle_sig_alarm() prevent any
eventual ProcessInterrupts() in the timeout handlers from doing anything
harmful?
Even if so, making sure ImmediateInterruptOK is preserved seems worthwile
anyway.

> And while we're on the subject ... isn't bgworker_die() utterly and
> completely broken?  That unconditional elog(FATAL) means that no process
> using that handler can do anything remotely interesting, like say touch
> shared memory.

Yes, looks broken to me.

> I didn't find any other similar hazards in a quick look through all our
> signal handlers.

One thing I randomly noticed just now is the following in
RecoveryConflictInterrupt():elog(FATAL, "unrecognized conflict mode: %d",     (int) reason);
obviously that's not really ever going to hit, but it should either be a
PANIC or an Assert() for the reasons you cite.

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: Alvaro Herrera
Date:
Subject: Re: pgsql: Fix a couple of bugs in MultiXactId freezing