Re: Review: Extra Daemons / bgworker

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: kaigai(at)kaigai(dot)gr(dot)jp, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: Extra Daemons / bgworker
Date: 2012-12-03 15:17:37
Message-ID: 50BCC291.7000201@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/03/2012 03:28 PM, Alvaro Herrera wrote:
> I'm not really that interested in it currently ... and there are enough
> other patches to review. I would like bgworkers to mature a bit more
> and get some heavy real world testing before we change autovacuum.

Understood.

>> Just like av_launcher does it now: set a flag in shared memory and
>> signal the postmaster (PMSIGNAL_START_AUTOVAC_WORKER).
>
> I'm not sure how this works. What process is in charge of setting such
> a flag?

The only process that currently starts background workers ... ehm ...
autovacuum workers is the autovacuum launcher. It uses the above
Postmaster Signal in autovacuum.c:do_start_autovacuum_worker() to have
the postmaster launch bg/autovac workers on demand.

(And yes, this kind of is an exception to the rule that the postmaster
must not rely on shared memory. However, these are just flags we write
atomically, see pmsignal.[ch])

I'd like to extend that, so that other processes can request to start
(pre-registered) background workers more dynamically. I'll wait for an
update of your patch, though.

> This is actually a very silly bug: it turns out that guc.c obtains the
> count of workers before workers have actually registered. So this
> necessitates some reshuffling.

Okay, thanks.

Regards

Markus Wanner

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-12-03 15:19:41 Re: Proposal for Allow postgresql.conf values to be changed via SQL
Previous Message Kohei KaiGai 2012-12-03 14:59:11 Re: [v9.3] OAT_POST_ALTER object access hooks