Re: Add mode column to pg_stat_progress_vacuum

From: Shinya Kato <shinya11(dot)kato(at)gmail(dot)com>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add mode column to pg_stat_progress_vacuum
Date: 2025-08-15 04:19:02
Message-ID: CAOzEurTQcVR44zL+EpDO9aZpsJ=XdDpR079wqWP-DnO1jqvd+g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 14, 2025 at 9:20 PM Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
>
> On Thu, 14 Aug 2025 at 16:13, Shinya Kato <shinya11(dot)kato(at)gmail(dot)com> wrote:
>
> > This patch introduces a mode column to provide this visibility. The
> > possible values are:
> > - normal: A standard, user-initiated VACUUM or a regular autovacuum run.
> > - anti-wraparound: An autovacuum run launched specifically to prevent
> > transaction ID wraparound.
> > - failsafe: A vacuum that has entered failsafe mode to prevent
> > imminent transaction ID wraparound.
>
> > Thought?
>
> Just a small comment:
>
> I am more used to Lazy vs Eager vacuum types. It is how we use to call
> them in doc and code. Maybe this wording will be better?

Thanks for the feedback!

Are you suggesting it would be better to change "normal" to "lazy" and
"anti-wraparound" to "eager"? My hesitation is that "lazy" is a term
used to contrast with VACUUM FULL, and the "lazy" vs. "eager"
distinction also exists for tuple freezing logic within vacuum.
Reusing these terms for a different purpose could be confusing. I also
find "anti-wraparound" to be a much clearer and more descriptive term
than "eager".

Unless there’s a strong preference otherwise, I’d like to keep
“anti-wraparound” and “failsafe” as-is, and keep “normal” (or possibly
“plain”/“regular” if that reads better).

--
Best regards,
Shinya Kato
NTT OSS Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2025-08-15 04:37:32 Re: [PATCH] bms_prev_member() can read beyond the end of the array of allocated words
Previous Message Tom Lane 2025-08-15 03:42:23 Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options