Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Coping with backend crash in libpq

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

Next:From: Andreas ZeugswetterDate: 1998-07-29 15:14:32
Subject: AW: [HACKERS] Informix on Linux
Previous:From: Thomas G. LockhartDate: 1998-07-29 14:54:50
Subject: Informix on Linux

pgsql-interfaces by date

Next:From: SandeepDate: 1998-07-29 15:07:10
Subject: Problem in compilation
Previous:From: Sergey V. KryaczevskihDate: 1998-07-29 14:36:33
Subject: Re: [GENERAL] Old ODBC Driver references on website

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group