Re: [HACKERS] Coping with backend crash in libpq

> > I've just noticed that libpq doesn't cope very gracefully if the backend
> > exits when not in the middle of a query (ie, because the postmaster told
> > it to quit after some other BE crashed).  The behavior in psql, for
> > example, is that the next time you issue a query, psql just exits
> > without printing anything at all.  This is Not Friendly, especially
> > considering that the BE sent a nice little notice message before it quit.
> 
> 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.
> 
> However, I see psql setting the SIGPIPE handler all over the place, so I
> don't think that will work there.  How about SIGURG?  Oops, not portable
> for unix domain sockets.  Can we send a signal to the process, telling
> it the backend has exited.  We have that information now, so why not use
> it.  Define a signal handler for SIGURG or SIGUSR1, and have that print
> out a message.  If the app redefines that, it will get confused when we
> send the signal from the postmaster.  Oops, we can't send signals to the
> client because they may be owned by other users.
> 
> I am stumped.  Let me think about it.

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

-dg

David Gould            dg@illustra.com           510.628.3783 or 510.305.9468 
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
 - If simplicity worked, the world would be overrun with insects. -