Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database)
От | Heikki Linnakangas |
---|---|
Тема | Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database) |
Дата | |
Msg-id | 50AE6A63.3070509@vmware.com обсуждение исходный текст |
Ответ на | Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database) (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: [v9.3] Extra Daemons (Re: elegant and effective way
for running jobs inside a database)
|
Список | 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
В списке pgsql-hackers по дате отправления: