Re: Track skipped tables during autovacuum and autoanalyze
Yugo Nagata <nagata@sraoss.co.jp>
From: Yugo Nagata <nagata@sraoss.co.jp>
To: Sami Imseih <samimseih@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Pgsql Hackers
<pgsql-hackers@postgresql.org>
Date: 2026-04-27T11:32:07Z
Lists: pgsql-hackers
Attachments
On Wed, 22 Apr 2026 07:49:55 -0500 Sami Imseih <samimseih@gmail.com> wrote: Thank you for your comments! > > 1/ > > + relid = RangeVarGetRelid(vrel->relation, NoLock, false); > > Should this be called with "true" as the 3rd (missing_ok) argument, otherwise > we end up with an error instead of a "--- relation no longer exists" log. right? No, it should be false. If missing_ok is true, VACUUM (SKIP_LOCKED) on a not-existing table would emit a "skipping vacuum of ... --- relation no longer exists" message, but it should be "relation ... does not exist". > 2/ > > Can the isolation tests > src/test/isolation/specs/vacuum-skip-locked.spec be updated > to check pg_stat_user_tables as well? Yes, we can. I've attached an updated patch including that test. While working on the test, I noticed that skipped FULL VACUUM was counted in the previous patch, so I fixed it not to avoid counting those cases. > 3/ comment fix: > > This: > * Relation could not be opened hence generate if possible a log > > Should be: > * Relation could not be opened, hence generate if possible a log Fixed. The names of the new fields are still open. The current pattern is "last_skipped_..." and "skipped_..._count". Alternatively, we could use "..._last_skip" and "..._skip_count", which would be consistent with slotsync_skip_count and slosync_last_skip. Which do you think is better? Regards, Yugo Nagata -- Yugo Nagata <nagata@sraoss.co.jp>