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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
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-08 08:46:37
Message-ID: CA+U5nM+FaFs6xiyPaZnNCe0L2Qj-1iCN4cpEnTkeiHF6xtHcbQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Cédric Villemain 2012-06-08 08:51:03 Re: New Postgres committer: Kevin Grittner
Previous Message Kyotaro HORIGUCHI 2012-06-08 08:22:01 Skip checkpoint on promoting from streaming replication