Thread

Re: Track skipped tables during autovacuum and autoanalyze

Sami Imseih <samimseih@gmail.com> — 2026-05-15T00:59:18Z

> Doesn't these also require a PGSTAT_FILE_FORMAT_ID change?

right. that was missed. Fixed in the attached.

> There's also an asymmetric case for the skipped counters, is that intentional?
>
> | Command                                 | `skipped_vacuum_count` |
> `skipped_analyze_count` |
> |-----------------------------------------|------------------------|-------------------------|
> | `VACUUM (FULL, ANALYZE, SKIP_LOCKED) t` | 0                      | 1
>                       |
> | `VACUUM (ANALYZE, SKIP_LOCKED) t`       | 1                      | 1
>                       |
> | `VACUUM (FULL, SKIP_LOCKED) t`          | 0                      | 0

Yeah, this is because vacuum_count and last_vacuum also skip VACUUM FULL.
That was mentioned earlier in the thread.

> > Initially, I was concerned that something might go wrong if a concurrent
> > session performed DROP TABLE or ALTER TABLE RENAME between RangeVarGetRelidExtended()
> > and RangeVarGetRelid(), but I could not find any actual issue. Even when the table
> > name is changed, the correct statistics entry is updated correctly.
>
> A DROP TABLE can cause a missed skip in statistics, which is
> reproducible with a custom injection point and tap test, see the
> attached patch. The race window is quite minimal, but it exists.

If the table is dropped, there are no stats to update. right?

--
Sami