Re: Add autovacuum_warning to surface concurrent vacuum collisions

Hi,

On Mon, Jun 1, 2026 at 5:34 AM Shinya Kato <shinya11(dot)kato(at)gmail(dot)com> wrote:
>
> The goal is to give DBAs an early signal that autovacuum is no longer
> keeping up, while there is still time to tune the configuration and
> avoid the worst outcomes (severe bloat, transaction ID wraparound).
> Today, by the time the existing wraparound warnings or anti-wraparound
> vacuums appear, the system is already in trouble; there is no earlier
> hint that autovacuum is becoming saturated.
>
> Design:
>
> When autovacuum_warning is enabled and a worker skips a table because
> another worker is already vacuuming it, the following is written to
> the server log:
>
> LOG: autovacuum: table "public.foo" is already being vacuumed by
> another worker
> HINT: Consider tuning the autovacuum configuration parameters.
>
> The hint is intentionally generic: a collision has no single root
> cause, and pointing at one specific parameter could be misleading.

Right, but unlike the checkpointer message which says exactly what to
do "increase max_wal_size", this hint leaves one with nothing specific
to tune or take care of. Without the relevant parameters and their
current values, it's hard to make anything meaningful out of it.

Can we avoid adding a GUC just for this? If we agree it's worth
emitting this information, after clarifying what exactly to tune when
this situation is hit, then maybe we could just add it to
pg_stat_all_tables instead - something like
autovacuum_concurrent_skip_count, similar to autovacuum_count and its
friends - and explain nicely in the docs what to look for when this
counter starts growing for a table.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com