2012/6/8 Simon Riggs <si...@2ndquadrant.com>: > On 25 April 2012 10:40, Kohei KaiGai <kai...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
