Re: Review: Extra Daemons / bgworker

Поиск
Список
Период
Сортировка
От Markus Wanner
Тема Re: Review: Extra Daemons / bgworker
Дата
Msg-id 50BCC291.7000201@bluegap.ch
обсуждение исходный текст
Ответ на Re: Review: Extra Daemons / bgworker  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Review: Extra Daemons / bgworker
Re: Review: Extra Daemons / bgworker
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.3] OAT_POST_ALTER object access hooks
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Proposal for Allow postgresql.conf values to be changed via SQL