Re: Track skipped tables during autovacuum and autoanalyze

From: Shinya Kato <shinya11(dot)kato(at)gmail(dot)com>
To: Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>
Cc: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: Track skipped tables during autovacuum and autoanalyze
Date: 2026-09-16 12:48:29
Message-ID: CAOzEurRddqm-etFkG9T4auovYUDdB1bBasNJGg1jW09tXcOmTg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for updating the patches!

On Tue, Sep 15, 2026 at 4:43 AM Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> wrote:
> This is less about stats reporting and more about filtering out such
> relations earlier in expand_vacuum_rel() for manually specified
> VACUUM/ANALYZE targets. Not a big thing, but it would avoid an extra
> syscache lookup and a misleading "lock not available" warning.

I would like to fold one more case into that follow-up. The skip is
reported before vacuum_is_permitted_for_relation(), so a user with no
rights on the table can still move its counters.

The callback argument of RangeVarGetRelidExtended() looks like the
right place for all of this. It runs before the lock attempt, and the
comment there already says that is where permission checks belong. It
also hands us relId, so expand_vacuum_rel() would no longer need the
second RangeVarGetRelid(..., NoLock, true) lookup.

--
Shinya Kato
NTT OSS Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Manuel Reyes Bravo 2026-09-16 12:58:33 Re: pgsql: Revert online data checksum transitions
Previous Message Daniel Gustafsson 2026-09-16 12:43:15 Re: pgsql: Revert online data checksum transitions