Andres Freund <and...@2ndquadrant.com> writes:
> Note that we're *inside* recv() here.
Well, actually, the recv() has probably failed with an EINTR at this
point, or else it will when/if control returns.
>> Uh, no, that would pretty much destroy the point of trying to report
>> an error message at all.
> I only mean that we should do so in scenarios where we're currently
> reading from the client. For die(), while we're reading from the client,
> we're sending a message the client doesn't expect - and thus
> unsurprisingly doesn't report.
This is nonsense. The client will see the error as a response to its
query. Of course, if it gets an EPIPE it might complain about that first
-- but that would only be likely to happen with a multi-packet query
string, at least over a TCP connection.
Experimenting with this on a RHEL6 box, I do see the "FATAL: terminating
connection due to administrator command" message if I SIGTERM a backend
while idle and it's using a TCP connection; psql sees that as a response
next time it issues a command. I do get the EPIPE behavior over a
Unix-socket connection, but I wonder if we shouldn't try to fix that.
It would make sense to see if there's data available before complaining
about the EPIPE.
Don't currently have an SSL configuration to experiment with.
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
