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 по дате отправления: