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

From Simon Riggs
Subject Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database)
Date
Msg-id CA+U5nM+FaFs6xiyPaZnNCe0L2Qj-1iCN4cpEnTkeiHF6xtHcbQ@mail.gmail.com
Whole thread Raw
In response to [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database)  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database)
List pgsql-hackers
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.

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.

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.

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?

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Skip checkpoint on promoting from streaming replication
Next
From: Cédric Villemain
Date:
Subject: Re: New Postgres committer: Kevin Grittner