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

Re: [HACKERS] Coping with backend crash in libpq

From: dg(at)illustra(dot)com (David Gould)
To: maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian)
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, 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 05:16:02
Message-ID: (view raw or whole thread)
Lists: pgsql-hackerspgsql-interfaces
> > 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. 


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. -

In response to

pgsql-hackers by date

Next:From: Robert NoskoDate: 1998-07-29 14:30:44
Previous:From: Bruce MomjianDate: 1998-07-29 04:59:32
Subject: Re: [HACKERS] Coping with backend crash in libpq

pgsql-interfaces by date

Next:From: rony khouryDate: 1998-07-29 07:15:12
Subject: not permanent insert into stud values('myname')
Previous:From: Bruce MomjianDate: 1998-07-29 04:59:32
Subject: Re: [HACKERS] Coping with backend crash in libpq

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