Re: Signals in a BGW

On 12/04/2017 08:03 PM, Craig Ringer wrote:

> pglogical sets up its own handler 'handle_sigterm'. However, it now does
> much the same as src/backend/tcop/postgres.c's 'die' function. ...
> 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.
>
> ...
> Personally I'd rather change the default bgw handler to 'die', make the
> sample bgworkers use CHECK_FOR_INTERRUPTS() properly, and be done

Short of reaching consensus to change the default bgw handler to 'die',
am I right to think any bgw that wanted to could set its own SIGTERM
handler to 'die' (its default SIGINT handler already being the normal
StatementCancelHandler), and use CHECK_FOR_INTERRUPTS(), and be cool?

> 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...

That does seem bold, doesn't it? I see there's a direct ereport(ERROR
in the standard FloatExceptionHandler also. Does that get exercised
much? I tried a quick select '1.0'::float8 / '0.0'::float8; but got
a more-specific 22012 division by zero, so it looks like such things
are mostly checked early and SIGFPE should be rare.

-Chap