Re: [HACKERS] Function to kill backend - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] Function to kill backend
Date
Msg-id 7254.1090701355@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Function to kill backend  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [HACKERS] Function to kill backend
List pgsql-patches
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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.

After further consideration I have concluded that this was a
spectacularly bad idea and we should revert that patch.  There is a very
large amount of processing that this patch will cause to happen after a
FATAL error has been declared, and I doubt that any of it is a good
idea.  Some examples:

* AbortCurrentTransaction() --- not too cool if the FATAL error was one
  of the ones in xact.c that are complaining of fatally bollixed
  transaction state.

* pgstat reporting --- aside from the chance of an outright crash, we
  might be transmitting bogus statistics to the collector.

* sending a ReadyForQuery (Z) message --- one thing we quite certainly
  ain't is ReadyForQuery.

* EnableNotifyInterrupt --- this may result in actually trying to run
  a transaction to look through pg_listener :-(

* ProcessConfigFile, if we had a pending SIGHUP --- also not too cool,
  if the FATAL was from guc.c.


I am still dubious that zapping random backends with SIGTERM is a sane
or supportable idea.  But this patch does not make things better, it
simply greatly increases the chance of a FATAL exit turning into a
backend crash or PANIC.

            regards, tom lane

pgsql-patches by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: Pipe fixes for win32 services
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Function to kill backend