From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgreSQL.org
To: pgsql-interfaces@postgreSQL.org
Subject: Re: [HACKERS] Coping with backend crash in libpq
Date: Wed, 29 Jul 1998 11:02:26 -0400
Message-ID: <7455.901724546@sss.pgh.pa.us> (raw)
In-Reply-To: <9807290516.AA02881@hawk.illustra.com>
>> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Coping with backend crash in libpq
In-Reply-To: <7455.901724546@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox