Re: Add autovacuum_warning to surface concurrent vacuum collisions

On Sat, Jun 27, 2026 at 3:53 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> 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.

I like this better than the GUC. A growing per-table counter is
something a DBA can watch over time and reason about. So I would like
to drop the GUC and pursue a per-table counter instead.

That surface is already being built in the "Track skipped tables
during autovacuum and autoanalyze" thread [1], which adds
skipped-vacuum and skipped-analyze counters to pg_stat_all_tables for
tables skipped when a lock cannot be acquired. I raised the
concurrent-worker skip there [2] as another skip reason worth tracking
on the same surface. It needs its own discussion, so I plan to take it
up in that thread or start a new one, rather than here.

[1] https://www.postgresql.org/message-id/20260324151133.7940a5c1f2ebd594d54da481%40sraoss.co.jp
[2] https://www.postgresql.org/message-id/CAOzEurSn7YDLLNnZW6etRJ167ZG4hvdaYDxeX5qwy%2BtuOFe4Dw%40mail.gmail.com

--
Best regards,
Shinya Kato
NTT OSS Center