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

Re: [HACKERS] Function to kill backend

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>,Dave Page <dpage(at)vale-housing(dot)co(dot)uk>,Magnus Hagander <mha(at)sollentuna(dot)net>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Josh Berkus <josh(at)agliodbs(dot)com>,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Function to kill backend
Date: 2004-07-26 21:36:36
Message-ID: 10020.1090877796@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Oliver Jowett <oliver(at)opencloud(dot)com> writes:
> What about implementing "kill" as "cancel then exit"? Does that 
> guarantee a safe exit in all cases?

That was exactly what Bruce's patch turned it into.  That would be
workable if we separated this case from the existing elog(FATAL)
behavior, but doing it that way is quite unsafe for real FATAL errors,
and I do not think we want SIGTERM response to behave that way either.
(When init SIGTERMs us, we do *not* want to lollygag around, we want
to get the heck out of there so we can write a shutdown checkpoint
before we get SIGKILL'd.)

So what you'd basically need is a separate signal to trigger that sort
of exit, which would be easy ... if we had any spare signal numbers.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Oliver JowettDate: 2004-07-26 21:53:48
Subject: Re: [HACKERS] Function to kill backend
Previous:From: Oliver JowettDate: 2004-07-26 21:22:33
Subject: Re: [HACKERS] Function to kill backend

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