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