Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database)

Heikki Linnakangas <hlinnakangas@vmware.com>

From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Kohei KaiGai <kaigai@kaigai.gr.jp>, Simon Riggs <simon@2ndquadrant.com>, Andrew Dunstan <andrew@dunslane.net>, Robert Haas <robertmhaas@gmail.com>, "David E. Wheeler" <david@justatheory.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-11-22T18:09:39Z
Lists: pgsql-hackers
On 22.11.2012 19:18, Alvaro Herrera wrote:
> Heikki Linnakangas escribió:
>> On 21.11.2012 23:29, Alvaro Herrera wrote:
>>> Alvaro Herrera escribió:
>>>> The UnBlockSig stuff is the main stumbling block as I see it because it
>>>> precludes compilation on Windows.  Maybe we should fix that by providing
>>>> another function that the module is to call after initialization is done
>>>> and before it gets ready to work ... but having a function that only
>>>> calls PG_SETMASK() feels somewhat useless to me; and I don't see what
>>>> else we could do in there.
>>>
>>> I cleaned up some more stuff and here's another version.  In particular
>>> I added wrapper functions to block and unblock signals, so that this
>>> doesn't need exported UnBlockSig.
>>
>> Could you just unblock the signals before calling into the
>> background worker's main() function?
>
> Yes, but what if a daemon wants to block/unblock signals later?

Ok. Can you think of an example of a daemon that would like to do that?

Grepping the backend for "BlockSig", the only thing it seems to be 
currenlty used for is to block nested signals in the SIGQUIT handler 
(see bg_quickdie() for an example). The patch provides a built-in 
SIGQUIT handler for the background workers, so I don't think you need 
BlockSig for that. Or do you envision that it would be OK for a 
background worker to replace the SIGQUIT handler with a custom one?

Even if we provide the BackgroundWorkerBlock/UnblockSignals() functions, 
I think it would still make sense to unblock the signals before calling 
the bgworker's main loop. One less thing for the background worker to 
worry about that way. Or are there some operations that can't be done 
safely after unblocking the signals? Also, I note that some worker 
processes call sigdelset(&BlockSig, SIGQUITE); that remains impossible 
to do in a background worker on Windows, the 
BackgroundWorkerBlock/UnblockSignals() wrapper functions don't help with 
that.

Some documentation on what a worker is allowed to do would be helpful here..

- Heikki