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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers