Re: Why is autovacuum_freeze_max_age a postmaster setting?

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 asynchronously from 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't wrapped my head around the issue with calling this straight from guc.c yet...)
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net