From: dg@illustra.com
To: maillist@candle.pha.pa.us
Cc: tgl@sss.pgh.pa.us
Cc: pgsql-hackers@postgreSQL.org
Cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [HACKERS] Coping with backend crash in libpq
Date: Tue, 28 Jul 1998 22:16:02 -0700 (PDT)
Message-ID: <9807290516.AA02881@hawk.illustra.com> (raw)
In-Reply-To: <199807290459.AAA25951@candle.pha.pa.us>
> > 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. -
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: dg@illustra.com, maillist@candle.pha.pa.us, tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Coping with backend crash in libpq
In-Reply-To: <9807290516.AA02881@hawk.illustra.com>
* 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