Re: Signals in a BGW

On 5 December 2017 at 00:40, Chapman Flack  wrote:

>
> Is there a known, default behavior that some signals will
> have, if I simply BackgroundWorkerUnblockSignals() without customizing?
> Will SIGINT and SIGTERM, for example, have default handlers that
> interact with the volatile flags in miscadmin.h that are used by
> CHECK_FOR_INTERRUPTS, and set the process latch?
>
>
The default handler is bgworker_die ; see src/backend/postmaster/bgworker.c
. I don't know if elog() is safe in a signal handler, but I guess in the
absence of non-reentrant errcontext functions...


pglogical sets up its own handler 'handle_sigterm'. However, it now does
much the same as src/backend/tcop/postgres.c's 'die' function, just without
the single-user mode checks.

void
handle_sigterm(SIGNAL_ARGS)
{
    int         save_errno = errno;

    SetLatch(MyLatch);

    if (!proc_exit_inprogress)
    {
        InterruptPending = true;
        ProcDiePending = true;
    }

    errno = save_errno;
}


so it's not significantly different. We used to have our own signal
handling but it gets seriously messy when you're calling into arbitrary
PostgreSQL code that expects CHECK_FOR_INTERRUPTS() to work.


> I notice that the worker_spi example code customizes SIGHUP
> and SIGTERM, giving them handlers that set a (different, local
> to the module) volatile flag, and set the process latch.
>

IMO it's silly to customise them, and a bad example.

Personally I'd rather change the default bgw handler to 'die', make the
sample bgworkers use CHECK_FOR_INTERRUPTS() properly, and be done with it.

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services