Hi,
> The current range 1..INT_MAX/1000 is indeed pretty wide, but I think
> it's hard, or even impossible, to conclude that no one would ever
> want more than X. Could the documentation be improved perhaps?
Yes, 0001 does that. The docs now say that a large value delays all
autovacuum work in a database, wraparound vacuums included, and that
raising it only helps clusters with very many databases. It stands on
its own.
> I’ve heard through various channels that `autovacuum_naptime`
> was mistakenly set to 23 hours, resulting in an XID wraparound incident.
We also had customer runs into that issue before.
In general, I agree with wenhui that 3600 is fine, because I can't
find a downside.
The only thing a larger value changes is how often
a worker starts in each database. Starting a worker costs about 13ms
of CPU here, with empty databases or with 2000 tables in each. So at
naptime 1h, all the worker starts in a cluster with 1000 databases
cost about 0.4% of one core, and with 10000 databases about 4%. That
is everything a larger value could save.
My understanding is that a cluster that large runs on a big machine,
so saving that much CPU means nothing in practice.
0002 lowers the max to 3600. Two notes on it.
contrib/test_decoding/logical.conf sets 1d to keep autovacuum quiet,
so I changed it to autovacuum = off
An old config above the new max stops the server from starting, so
0002 is for master only.
Thanks,
Shihao
