Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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 the elbow of proc_exit, nor an already-in-progress
        <    * abort
        <    */
        <   if (!proc_exit_inprogress && !InError)
        ---
        >   /* Don't joggle 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 the interrupt immediately.  No point in interrupting if
        <        * we're waiting for input, however.
        ---
        >        * If it's safe to interrupt, and we're waiting for input or a
        >        * lock, service the interrupt immediately
        26,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:
        
        void
        ProcessInterrupts(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;   /* not idle 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 was reset) */
        }

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
  [EMAIL PROTECTED]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html

Reply via email to