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(at)illustra(dot)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. -