Re: Signals in a BGW

2017-12-07 Thread Chapman Flack
On 12/07/2017 02:58 PM, Andres Freund wrote: > On 2017-12-07 12:35:07 -0500, Robert Haas wrote: >> On Wed, Dec 6, 2017 at 6:59 PM, Chapman Flack wrote: The default handler is bgworker_die ; see src/backend/postmaster /bgworker.c . I don't know if elog() is safe in a signal handler,

Re: Signals in a BGW

2017-12-07 Thread Andres Freund
On 2017-12-07 12:35:07 -0500, Robert Haas wrote: > On Wed, Dec 6, 2017 at 6:59 PM, Chapman Flack wrote: > >> 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

Re: Signals in a BGW

2017-12-07 Thread Robert Haas
On Wed, Dec 6, 2017 at 6:59 PM, Chapman Flack wrote: >> 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 i

Re: Signals in a BGW

2017-12-06 Thread Chapman Flack
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 >

Re: Signals in a BGW

2017-12-04 Thread Michael Paquier
On Tue, Dec 5, 2017 at 10:03 AM, 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, just without > the single-user mode checks. Documentation shows a simple example of that: https://www.po

Re: Signals in a BGW

2017-12-04 Thread Craig Ringer
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 miscad

Signals in a BGW

2017-12-04 Thread Chapman Flack
I'm curious about handling signals in a background worker. As I understand it, these are blocked when the BGW is born, until enabled with BackgroundWorkerUnblockSignals() after possible customization. Is there a known, default behavior that some signals will have, if I simply BackgroundWorkerUnbl