Re: allow changing autovacuum_max_workers without restarting

On Mon, Jan 06, 2025 at 06:36:43PM -0500, Tom Lane wrote:
> Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
>> My first instinct was just to set it to the lowest default we'd consider
>> during the max_connections tests (which I'm assuming is 3 due to the
>> current default for autovacuum_max_workers). That way, the max_connections
>> default won't change from version to version on affected systems, but you
>> might get some extra autovacuum slots.
>
> My only objection to this algorithm is it adds cycles to initdb,
> in the form of at least one additional "postgres --check" step.
> Admittedly that's not hugely expensive, but it'll add up over time
> in the buildfarm, and I'm not sure this issue is worth that.
> We already changed the max_connections default for affected systems
> as a consequence of 38da05346, so I don't think the argument about not
> changing it holds much water.

I see. Here's a version that uses your max_connections / 8 idea. I've
lowered the initial default value of autovacuum_worker_slots to 12 to keep
the code as simple as possible. I considered trying 16 in the first
iteration or constructing a complicated formula like

autovacuum_worker_slots = (max_connections * 13) / 75 - 1

but this stuff is pretty fragile already, so I felt that simplicity was
desirable in this case.

--
nathan