Re: Why is autovacuum_freeze_max_age a postmaster setting? - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Why is autovacuum_freeze_max_age a postmaster setting?
Date
Msg-id 532CB7EC.8060807@nasby.net
Whole thread Raw
In response to Re: Why is autovacuum_freeze_max_age a postmaster setting?  (Andres Freund <andres@2ndquadrant.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease
Next
From: Bruce Momjian
Date:
Subject: Re: [RFC] What should we do for reliable WAL archiving?