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.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)