Andres Freund <and...@2ndquadrant.com> writes:
> 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?
We do that *only at safe spots*, ie CHECK_FOR_INTERRUPTS. Or at least
I sure hope so. Otherwise interrupting, eg, malloc will lead to much
unhappiness.
> BUT: why is what ProcessInterrupts() is doing safe? Shouldn't it always
> at least set whereToSendOutput = DestNone when FATALing while reading
> (potentially via openssl)?
Uh, no, that would pretty much destroy the point of trying to report
an error message at all.
We do restrict the immediate interrupt to occur only while we're actually
doing a recv(), see prepare_for_client_read and client_read_ended.
I grant that in the case of an SSL connection, that could be in the middle
of some sort of SSL handshake, so it might not be completely safe
protocol-wise --- but it's not likely to mean instant data structure
corruption.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
