[HACKERS] Why is autovacuum_freeze_max_age a postmaster setting?
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?) -- Jim C. Nasby, Data Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why is autovacuum_freeze_max_age a postmaster setting?
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? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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 j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers