Hi, On Mon, Jun 1, 2026 at 5:34 AM Shinya Kato <[email protected]> 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
