Re: Why is autovacuum_freeze_max_age a postmaster setting?

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Why is autovacuum_freeze_max_age a postmaster setting?
Дата
Msg-id 532CB7EC.8060807@nasby.net
обсуждение исходный текст
Ответ на Re: Why is autovacuum_freeze_max_age a postmaster setting?  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On 3/21/14, 4:55 PM, Andres Freund wrote:
> Hi,
>
> On 2014-03-21 16:49:53 -0500, Jim Nasby wrote:
>> Why do we require a restart to change autovacuum_freeze_max_age? Can’t
>> we respawn the autovac workers to pick up the setting? (Or just pass
>> the HUP down to them?)
>
> It's more complex than notifying the workers. There's limits in shared
> memory that's computed based on it. Check
> varsup.c:SetTransactionIdLimit(). It's not entirely trivial to trigger
> recomputation of that value via the GUC machinery in a sensible way...
>
> But yes, I'd wished it were PGC_SIGHUP before as well.
>
> I guess we could delegate responsibility of updating the shared memory
> value to the autovac launcher?

Does the launcher handle the SIGHUP for autovac workers?

But generally speaking, yes, I think it would be sensible to only worry about the effect that setting has
asynchronouslyfrom what guc.c does, *as long as* it will always be set, regardless of things like the autovac GUC.
 

Also, maybe we should split setting ShmemVariableCache->xidVacLimit into it's own function? Would that help? (Sorry, I
haven'twrapped my head around the issue with calling this straight from guc.c yet...)
 
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [RFC] What should we do for reliable WAL archiving?