Nathan Bossart <nathandboss...@gmail.com> writes:
> On Mon, Jan 06, 2025 at 05:36:17PM -0500, Tom Lane wrote:
>> You'd have to think about how
>> it should interact with initdb's probes for workable values of
>> max_connections. My first thought about that is to have initdb
>> set autovacuum_worker_slots to max_connections / 8 or thereabouts
>> as it works down the list of max_connections values to try. Or
>> you could do something more complicated, but I don't see a reason
>> to make it too complex.
> 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.
regards, tom lane
