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