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
