Re: Add autovacuum_warning to surface concurrent vacuum collisions

Hi,

On Mon, Jul 13, 2026 at 11:06 PM Shinya Kato <shinya11(dot)kato(at)gmail(dot)com> wrote:
>
> 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.
>
> 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

Thanks. I came across the CF entry for this
https://commitfest.postgresql.org/patch/6830/. Since you plan to
discuss this in [1] which already has a CF entry, can we close this
one?

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