From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org, pgsql-interfaces(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Coping with backend crash in libpq |
Date: | 1998-07-29 15:02:26 |
Message-ID: | 7455.901724546@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-interfaces |
>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Zeugswetter | 1998-07-29 15:14:32 | AW: [HACKERS] Informix on Linux |
Previous Message | Thomas G. Lockhart | 1998-07-29 14:54:50 | Informix on Linux |
From | Date | Subject | |
---|---|---|---|
Next Message | Sandeep | 1998-07-29 15:07:10 | Problem in compilation |
Previous Message | Sergey V. Kryaczevskih | 1998-07-29 14:36:33 | Re: [GENERAL] Old ODBC Driver references on website |