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