Re: Do we reduce autovacuum_naptime max values

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