Do we reduce autovacuum_naptime max values

On 9 Sep 2026, at 11:49, wenhui qiu <qiuwenhuifx@gmail.com> wrote:

I’ve heard through various channels that `autovacuum_naptime` was mistakenly
set to 23 hours, resulting in an XID wraparound incident. Maybe the max value
of more than 1 hour is too large ,so can we reduce the max value to 3600? Of
course, an inappropriate XID request is also a contributing factor to the
incident.We believe a reasonable range should be set for this maximum value.

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?

--
Daniel Gustafsson

I have seen similar issues with other flags. Specifically, without
careful consultation of the documentation, it is easy to misconfigure
these parameters due to the varying default unit semantics.

This made me think about the vacuum failsafe mechanism. Although the
failsafe successfully overrides certain cost and delay restrictions to
speed up anti-wraparound vacuuming once a vacuum process kicks in, an
accidentally high naptime creates a scheduling bottleneck. It prevents
the launcher from initiating the autovacuum processes in the first
place.

Thanks,
Virender

HI Daniel

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?

Actually, I believe that lowering this value to a reasonable range is the
most fundamental solution. By reducing the maximum value of this parameter,
an error message will appear if it is set incorrectly, which can prevent
disasters caused by incorrect settings. Moreover, lowering this value to
3600 seconds is still an unreasonably high value—but it’s at least much
better than setting it to 23 hours.Personally, I think anything over 10
minutes is unacceptable.

Thanks

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