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

2012/6/8 Simon Riggs <simon@2ndquadrant.com>:
> On 25 April 2012 10:40, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>
>> I tried to implement a patch according to the idea. It allows extensions
>> to register an entry point of the self-managed daemon processes,
>> then postmaster start and stop them according to the normal manner.
>
> The patch needs much work yet, but has many good ideas.
>
> There doesn't seem to be a place where we pass the parameter to say
> which one of the multiple daemons a particular process should become.
> It would be helpful for testing to make the example module call 2
> daemons each with slightly different characteristics or parameters, so
> we can test the full function of the patch.
>
This patch intended to register a daemon multiple times with different
name such as "auth-counter-1" or "auth-counter-2".
But, I agree with the suggestion to take a parameter to identify each
daemon makes interface better than the original one.

> I think its essential that we allow these processes to execute SQL, so
> we must correctly initialise them as backends and set up signalling.
> Which also means we need a parameter to limit the number of such
> processes.
>
It should be controllable with a flag of RegisterExtraDaemon().
Although it helps to reduce code duplication in case when extra daemons
execute SQL, but some other use-cases may not need SQL execution.

> Also, I prefer to call these bgworker processes, which is more similar
> to auto vacuum worker and bgwriter naming. That also gives a clue as
> to how to set up signalling etc..
>
> I don't think we should allow these processes to override sighup and
> sigterm. Signal handling should be pretty standard, just as it is with
> normal backends.
>
Hmm. CHECK_FOR_INTERRUPTS() might be sufficient to handle
signaling behavior according to the standard.

> I have a prototype that has some of these characteristics, so I see
> our work as complementary.
>
> At present, I don't think this patch would be committable in CF1, but
> I'd like to make faster progress with it than that. Do you want to
> work on this more, or would you like me to merge our prototypes into a
> more likely candidate?
>
I'm not favor in duplicate similar efforts. If available, could you merge
some ideas in my patch into your prototypes?

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>