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

From Nathan Bossart
Subject Re: Add mode column to pg_stat_progress_vacuum
Date
Msg-id aOUr74QOWeMrGEVr@nathan
Whole thread Raw
In response to Add mode column to pg_stat_progress_vacuum  (Shinya Kato <shinya11.kato@gmail.com>)
Responses Re: Add mode column to pg_stat_progress_vacuum
List pgsql-hackers
On Thu, Aug 14, 2025 at 08:12:55PM +0900, Shinya Kato wrote:
> I would like to propose a patch that enhances the
> pg_stat_progress_vacuum view by adding a mode column. The patch is
> attached.
> 
> Although it is possible to identify an anti-wraparound VACUUM through
> the process title (to prevent wraparound) or specific log entries, it
> would be significantly more convenient for monitoring purposes to have
> this status clearly indicated in the pg_stat_progress_vacuum view.
> This would enable DBAs to immediately understand the urgency of the
> vacuum process without needing to check separate logs or system
> processes.

This seems generally reasonable to me.

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

I wonder if we should also add "aggressive".

> I was able to manually verify the failsafe mode's behavior by using
> the existing test script at
> src/test/modules/xid_wraparound/t/001_emergency_vacuum.pl. This script
> successfully triggered the failsafe condition and the view reported
> the correct mode. However, I found this test to be somewhat flaky in
> my environment and decided not to add it to the patch to avoid
> introducing a potentially unstable test into the tree.

Perhaps there's something we can do with injection points to improve the
stability of the test.

-- 
nathan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: psql: Count all table footer lines in pager setup
Next
From: Tomas Vondra
Date:
Subject: Re: Should we update the random_page_cost default value?