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: 200404110100.i3B10Sc24006@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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 | http://candle.pha.pa.us
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

Attachment Content-Type Size
unknown_filename text/plain 2.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message pgsql 2004-04-11 05:29:33 Re: PostgreSQL configuration
Previous Message Bruce Momjian 2004-04-10 23:49:23 Re: PostgreSQL configuration

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2004-04-11 01:06:02 Re: COPY for CSV documentation
Previous Message Andrew Dunstan 2004-04-11 00:50:00 Re: COPY for CSV documentation