Re: [HACKERS] Coping with backend crash in libpq

>> I say, install the signal handler for SIGPIPE on connection startup, but
>> when you install it, it returns the previous defined action.  If we find
>> there was a previous defined action, we can re-install theirs, and let
>> it handle the sigpipe.  If an application later defines it's own
>> sigpipe, over-riding ours, then they get no error message.

This makes our correct functioning dependent on the application's
SIGPIPE handler, which doesn't strike me as a good solution.
Another problem is that if we leave a SIGPIPE handler in place,
it will get called for SIGPIPEs on *other* pipes that the surrounding
application may have open, and we have no way to know what the right
response is.  (AFAIK a SIGPIPE handler can't even portably tell which
connection has SIGPIPEd.)

>> Can we send a signal to the process, telling
>> it the backend has exited.

No.  The client isn't necessarily even on the same machine as the
postmaster/backend.  Even if it were, I don't think we can take over
a signal code that the frontend application might be using for something
else.

> Hmmm, perhaps fix psql so that it uses SIGPIPE more sensibly. SIGPIPE really
> is the right signal to catch here.

Well, psql is also using SIGPIPE sensibly: it's trying to prevent a
hangup when sending data down a pipe to a subprocess that might
terminate early.  The real problem here is that SIGPIPE is designed
wrong.  It ought to be possible to enable/disable SIGPIPE on a per-
file-handle basis ... but AFAIK that's not possible, and it's certainly
not portable even if some Unixes support it.


I'm still in favor of the check-for-input-just-before-send solution.
That does leave a small window where we can fail, but really the failure
should be pretty improbable: you have to assume that some other backend
coredumps while yours is idle, and in a window of microseconds right
before you are going to send a new command to your backend.  I think the
mess-with-catching-SIGPIPE approach is actually more likely to have
problems in practice.  It could interfere with normal functioning of
the frontend app, whereas any possible failure of the other way requires
a previous failure in some backend.  Production backends shouldn't
coredump too darn often, one hopes.

            regards, tom lane