On 2014-06-29 12:53:56 -0400, Tom Lane wrote:
> I do not think it is: specifically, the notion
> that we will call ereport(FATAL) directly from a signal handler
> does not fill me with warm fuzzies.
Aren't we already pretty much doing that for
SIGTERM/pg_terminate_backend() and recovery conflict interrupts?
If we get a SIGTERM while reading a command die() will set
ProcDiePending() and call ProcessInterrupts() after disabling some other
interrupts. Then the latter will FATAL out.
Imo the idle timeout handler pretty much needs a copy of die(), just
setting a different variable than (or in addition to?) ProcDiePending.
BUT: why is what ProcessInterrupts() is doing safe? Shouldn't it always
at least set whereToSendOutput = DestNone when FATALing while reading
(potentially via openssl)? The current behaviour imo both a protocol
violation and dangerous because of what you explained?
> I'd be happier if this were implemented in the more traditional
> style where the signal handler just sets a volatile flag variable,
> which would be consulted at determinate places in the mainline logic.
> Or possibly it could be made safe if we only let it throw the error
> directly when ImmediateInterruptOK is true (compare the handling
> of notify/catchup interrupts).
Hm. That sounds approximately like what I've written above.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
