Re: Track skipped tables during autovacuum and autoanalyze
| От | Yugo Nagata |
|---|---|
| Тема | Re: Track skipped tables during autovacuum and autoanalyze |
| Дата | |
| Msg-id | 20260427203207.32aa6ca37f2a18a05508dfda@sraoss.co.jp обсуждение |
| Ответ на | Re: Track skipped tables during autovacuum and autoanalyze (Sami Imseih <samimseih@gmail.com>) |
| Список | pgsql-hackers |
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>
Вложения
В списке pgsql-hackers по дате отправления: