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

Re: [HACKERS] Function to kill backend

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>,Magnus Hagander <mha(at)sollentuna(dot)net>,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Function to kill backend
Date: 2004-04-11 01:00:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
I have applied the attached patch:

   Exit backend from SIGTERM or FATAL by simulating client EOF, rather than
   calling proc_exit() directly.  This should make SIGTERM more reliable.


Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > On first glance, I don't see anything dangerous about SIGTERM.
> You haven't thought about it very hard :-(
> The major difference I see is that elog(FATAL) will call proc_exit
> directly from elog, rather than longjmp'ing back to PostgresMain.
> The case that we have confidence in involves elog(ERROR) returning to
> PostgresMain and then calling proc_exit from there (in the path where
> we get EOF from the client).
> This leaves me with a couple of concerns:
> * Notice all that cleanup/reset stuff in the "if (sigsetjmp())" block
> in PostgresMain.  SIGTERM will cause proc_exit to be entered without
> any of that being done first.  Does it work reliably?  Shouldn't this be
> refactored to ensure the same things happen in both cases?
> * There are various places, especially in the PLs, that try to hook into
> error recovery by manipulating Warn_restart.  Will any of them have
> problems if their error recovery code doesn't get called during SIGTERM
> exit?
> One possible refactoring is for elog(FATAL) to go ahead and longjmp back
> to PostgresMain, and at the end of the error recovery block check a flag
> and do proc_exit() if we're fataling.  However I am not sure that this
> doesn't break the design for coping with elog's during proc_exit.
> Alvaro's nested-transaction work is another thing that's got to be
> thought about before touching this code.  I have not yet seen any design
> for error recovery in the nested xact case, but I am sure it's going to
> need some changes right around here.
> 			regards, tom lane

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-hackers by date

Next:From: pgsqlDate: 2004-04-11 05:29:33
Subject: Re: PostgreSQL configuration
Previous:From: Bruce MomjianDate: 2004-04-10 23:49:23
Subject: Re: PostgreSQL configuration

pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-04-11 01:06:02
Subject: Re: COPY for CSV documentation
Previous:From: Andrew DunstanDate: 2004-04-11 00:50:00
Subject: Re: COPY for CSV documentation

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