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

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@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