On Wed, Nov 12, 2025 at 8:50 PM Shinya Kato <[email protected]> wrote: > > On Thu, Nov 13, 2025 at 11:11 AM Masahiko Sawada <[email protected]> > wrote: > > + </para> > > + <para> > > + The trigger of the current vacuum operation. Possible values are: > > > > What caused the current VACUUM operation to be initiated. Possible values > > are: > > > > + <itemizedlist> > > + <listitem> > > + <para> > > + <literal>manual</literal>: Initiated by an explicit > > + <command>VACUUM</command> command. > > > > manual: The vacuum was initiated by an explicit VACUUM command. > > > > + <literal>autovacuum</literal>: Launched by autovacuum based on > > + <xref linkend="guc-autovacuum-vacuum-threshold"/> or > > + <xref linkend="guc-autovacuum-vacuum-insert-threshold"/>. > > > > autovacuum: The vacuum was started by an autovacuum worker. Autovacuum > > workers launched for this purpose are interrupted due to lock > > conflicts. > > > > + <literal>autovacuum_wraparound</literal>: Launched by autovacuum > > to > > + avoid transaction ID or multixact ID wraparound (see > > + <xref linkend="vacuum-for-wraparound"/> as well as > > + <xref linkend="guc-autovacuum-freeze-max-age"/> and > > + <xref linkend="guc-autovacuum-multixact-freeze-max-age"/>). > > > > autovacuum_wraparound: The vacuum was started by an autovacuum worker > > to prevent transaction ID or multixact ID wraparound. Autovacuum > > workers launched for this purpose are not interrupted because of lock > > conflicts. > > Fixed, but I have a comment. I noticed minor wording inconsistencies, > e.g., 'started' vs. 'initiated' and 'due to' vs. 'because of'. Should > I unify these terms?
+1
>
> > ---
> > + /* Reset the progress counters and the mode */
> > + pgstat_progress_update_multi_param(3, progress_index, progress_val);
> >
> > This change seems not correct to me since we don't reset the mode. I'd
> > change it to:
> >
> > /* Reset the progress counters and set the failsafe mode */
>
> Fixed.
>
Thank you for updating the patch! For the v4 patch,
@@ -808,6 +821,8 @@ heap_vacuum_rel(Relation rel, const VacuumParams params,
* visibility map (even those set all-frozen)
*/
vacrel->aggressive = true;
+ pgstat_progress_update_param(PROGRESS_VACUUM_MODE,
+ PROGRESS_VACUUM_MODE_AGGRESSIVE);
skipwithvm = false;
}
I think we can update the mode to 'normal' or 'aggressive' instead of
switching 'normal' to 'aggressive' here.
I've made minor changes to the v4 patch and attached the updated
patch. I'm going to push the patch unless there are other review
comments. Please review the patch.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
v5-0001-Add-mode-and-triggered_by-columns-to-pg_stat_prog.patch
Description: Binary data
