Re: Add mode column to pg_stat_progress_vacuum - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Add mode column to pg_stat_progress_vacuum
Date
Msg-id CAD21AoADSzaGBf-MyexNkefsx4C5CU5JgebZJPhd7piy9P1Vng@mail.gmail.com
Whole thread Raw
In response to Re: Add mode column to pg_stat_progress_vacuum  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Add mode column to pg_stat_progress_vacuum
List pgsql-hackers
On Tue, Oct 7, 2025 at 9:26 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> On Tue, Oct 07, 2025 at 11:50:46AM -0400, Robert Treat wrote:
> > On Tue, Oct 7, 2025 at 11:04 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
> >> I wonder if we should also add "aggressive".
> >
> > I don't think so. I feel like the point of the mode is to answer "why
> > is this vacuum running" not "how is it operating under the hood".
>
> To some extent, those are tied together.  For example, a failsafe vacuum is
> an anti-wraparound vacuum that skips index vacuuming, etc.  And an
> anti-wraparound vacuum implies an aggressive scan, but not vice versa.
> There's also a separate parameter (vacuum_freeze_table_age) that controls
> when vacuum decides to perform an aggressive scan, just like there exists a
> parameter for anti-wraparound vacuums (autovacuum_freeze_max_age) and
> failsafe vacuums (vacuum_failsafe_age).

Right. I think we cannot display both things in one mode column. Since
both manual vacuums and anti-wraparound autovacuums can enter the
failsafe mode dynamically, if we show "failsafe" in the mode column,
we would lose the information "why is this vacuum running". I guess we
would need separate columns. For example, I guess that the column
showing "how is it operating under the hood" can have three values:
"normal", "aggressive" (disables VM optimization), and "failsafe"
(implies aggressive vacuum and disables many things to prioritize XID
freezing).

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Shayon Mukherjee
Date:
Subject: Proposal for discussions: Allow reads to proceed during FK/trigger drops by reducing relation-level lock from AccessExclusive to ShareRowExclusive
Next
From: Robert Haas
Date:
Subject: Re: RFC: extensible planner state