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 по дате отправления: