From: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database) |
Date: | 2012-06-10 09:15:25 |
Message-ID: | CADyhKSW1GC=AyRdRTQcWSA+vSHZ9w98Tr2GxikZt574GZnLgbQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2012/6/8 Simon Riggs <simon(at)2ndquadrant(dot)com>:
> On 25 April 2012 10:40, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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(at)kaigai(dot)gr(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2012-06-10 10:23:31 | Re: incorrect handling of the timeout in pg_receivexlog |
Previous Message | Magnus Hagander | 2012-06-10 08:41:57 | Re: Visual Studio 2012 RC |