From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: bg worker: patch 1 of 6 - permanent process |
Date: | 2010-08-26 11:23:07 |
Message-ID: | 4C764E9B.5090305@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Itagaki-san,
On 08/26/2010 01:02 PM, Itagaki Takahiro wrote:
> OK, I see why you proposed coordinator hook (yeah, I call it hook :)
> rather than adding user-defined processes.
I see. If you call that a hook, I'm definitely not a hook-hater ;-) at
least not according to your definition.
> However, we have autovacuum worker processes in addition to normal backend
> processes. Does it show a fact that there are some jobs we cannot run in
> normal backends?
Hm.. understood. You can use VACUUM from a cron job. And that's the
problem autovacuum solves. So in a way, that's just a convenience
feature. You want the same for general purpose user defined background
processing, right?
> For example, normal backends cannot do anything in idle time, so a
> time-based polling job is difficult in backends. It might be ok to
> fork processes for each interval when the polling interval is long,
> but it is not effective for short interval cases. I'd like to use
> such kind of process as an additional stats collector.
Did you follow the discussion I had with Dimitri, who was trying
something similar, IIRC. See the bg worker - overview thread. There
might be some interesting bits thinking into that direction.
Regards
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-08-26 12:18:40 | Re: Committers info for the git migration - URGENT! |
Previous Message | Itagaki Takahiro | 2010-08-26 11:02:30 | Re: bg worker: patch 1 of 6 - permanent process |