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