Re: Track skipped tables during autovacuum and autoanalyze

On Thu, 14 May 2026 19:59:18 -0500
Sami Imseih <samimseih(at)gmail(dot)com> wrote:

> > Doesn't these also require a PGSTAT_FILE_FORMAT_ID change?
>
> right. that was missed. Fixed in the attached.

Thank you for updating the patch.

>
> > 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.

Right.

> > > 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?

In my analysis, even if the table is dropped or renamed just before calling RangeVarGetRelid()
(at the injection point you added), RangeVarGetRelid() still returns the table's OID. So it
seems possible that the statistics entry is updated locally, but it would be released shortly
afterward and thus eventually becomes invisible.

However, I'm not entirely sure whether this behavior is always guaranteed.
Could anyone clarify this?

Regards,
Yugo Nagata

--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>