Re: Track skipped tables during autovacuum and autoanalyze

On Thu, 5 Nov 2026 at 07:56, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote:
>
> On Thu, 5 Nov 2026 07:16:45 +0900
> Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> > On Wed, Nov 04, 2026 at 03:55:31PM -0600, Zsolt Parragi wrote:
> > > I have only one small comment/question: it seems like the
> > > PGSTAT_FILE_FORMAT_ID change was dropped between v14 and v15?
> >
> > That would be the kind of thing a committer would take care of once/if
> > committing such a patch. I'd suggest to add a notice to the commit
> > message of the sent patch instead, to not forget that the counter
> > needs a bump when/if it gets merged.
>
> Thank you for the suggestion.
>
> Attached is an updated patch with only the suggested comment added.

Thanks for the updated patch.
I reviewed v20 and found that a skip is recorded before any privilege
checks are performed. While a lock is held on a table, any role that
can see the table's schema can run:
VACUUM (SKIP_LOCKED) t;
ANALYZE (SKIP_LOCKED) t;

This allows the role to increment t's lock_skipped_vacuum_count /
lock_skipped_analyze_count and update the corresponding
last_lock_skipped_* timestamps, even if it has no privileges on the
table. Since it allows an unprivileged role to modify the shared
statistics of a table it cannot access.
Attached a patch which has the test to reproduce this issue.
Thoughts?

Regards,
Vignesh