Re: Function to kill backend - Mailing list pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > If there is a problem, maybe we can fix it, or perhap have the kill
> > function use SIGINT, then wait for the query to cancel, then SIGTERM.
> 
> Well, if someone could prove that the SIGTERM path is equivalent to
> a transaction-aborting error followed by normal client disconnect,
> I'd feel a lot better about its reliability.  We know those two code
> paths work well.
> 
> Right now I do not think they are equivalent, but maybe they could be
> made so.

I just did a whitespace-ignore diff of the SIGINT (which is cancel and
we know works), and SIGTERM (which is under study).  Here is a diff of
SIGINT vs. SIGTERM functions:
1,2c1,2< static void< StatementCancelHandler(SIGNAL_ARGS)---> void> die(SIGNAL_ARGS)6,10c6,7<   /*<    * Don't joggle
theelbow of proc_exit, nor an already-in-progress<    * abort<    */<   if (!proc_exit_inprogress && !InError)--->   /*
Don'tjoggle the elbow of proc_exit */>   if (!proc_exit_inprogress)13c10<       QueryCancelPending = true;--->
ProcDiePending= true;16,18c13,14<        * If it's safe to interrupt, and we're waiting for a lock,<        * service
theinterrupt immediately.  No point in interrupting if<        * we're waiting for input, however.--->        * If it's
safeto interrupt, and we're waiting for input or a>        * lock, service the interrupt immediately26,33c22,26<
  if (LockWaitCancel())<           {<               DisableNotifyInterrupt();<               InterruptHoldoffCount--;<
            ProcessInterrupts();<           }<           else<               InterruptHoldoffCount--;--->
DisableNotifyInterrupt();>          /* Make sure CheckDeadLock won't run while shutting down... */>
LockWaitCancel();>          InterruptHoldoffCount--;>           ProcessInterrupts();
 

The big difference seems to be the InError test, and the test in SIGINT
whether LockWaitCancel() actually returns true or false.  Also,
DisableNotifyInterrupt() is called before LockWaitCancel().

Also, one sets QueryCancelPending and the other ProcDiePending.  Those
are handled by:voidProcessInterrupts(void){    /* OK to accept interrupt now? */    if (InterruptHoldoffCount != 0 ||
CritSectionCount!= 0)        return;    InterruptPending = false;    if (ProcDiePending)    {        ProcDiePending =
false;       QueryCancelPending = false;     /* ProcDie trumps QueryCancel */        ImmediateInterruptOK = false;   /*
notidle anymore */        DisableNotifyInterrupt();        ereport(FATAL,
(errcode(ERRCODE_ADMIN_SHUTDOWN),        errmsg("terminating connection due to administrator command")));    }    if
(QueryCancelPending)   {        QueryCancelPending = false;        ImmediateInterruptOK = false;   /* not idle anymore
*/       DisableNotifyInterrupt();        ereport(ERROR,                (errcode(ERRCODE_QUERY_CANCELED),
 errmsg("canceling query due to user request")));    }    /* If we get here, do nothing (probably, QueryCancelPending
wasreset) */}
 

and the only difference here seems to be the elog(SHUTDOWN) call.

On first glance, I don't see anything dangerous about SIGTERM.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073