Re: Add mode column to pg_stat_progress_vacuum
От | Nathan Bossart |
---|---|
Тема | Re: Add mode column to pg_stat_progress_vacuum |
Дата | |
Msg-id | aOUr74QOWeMrGEVr@nathan обсуждение исходный текст |
Ответ на | Add mode column to pg_stat_progress_vacuum (Shinya Kato <shinya11.kato@gmail.com>) |
Ответы |
Re: Add mode column to pg_stat_progress_vacuum
Re: Add mode column to pg_stat_progress_vacuum |
Список | 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 по дате отправления: