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

On Thu, Nov 13, 2025 at 11:11 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> Thank you for updating the patch!

Thank you for the review!

> How about the following changes for the documentation changes?
>
> +      <para>
> +       The mode of the current vacuum operation.  Possible values are:
>
> The mode in which the current VACUUM operation is running. See Section
> 24.1.5 for details of each mode. Possible values are:
>
> +       <itemizedlist>
> +        <listitem>
> +         <para>
> +          <literal>normal</literal>: A standard vacuum operation that is not
> +          required to be aggressive and has not entered failsafe mode.
> +         </para>
>
> normal: The operation is performing a standard vacuum and is neither
> required to run in aggressive mode nor operating in failsafe mode.
>
> +        </listitem>
> +        <listitem>
> +         <para>
> +          <literal>aggressive</literal>: A vacuum that must scan the entire
> +          table because <xref linkend="guc-vacuum-freeze-table-age"/> or
> +          <xref linkend="guc-vacuum-freeze-min-age"/> (or the corresponding
> +          per-table storage parameters) required it, or because page skipping
> +          was disabled via <command>VACUUM (DISABLE_PAGE_SKIPPING)</command>.
>
> aggressive: The operation is running an aggressive vacuum that must
> scan every page that is not marked all-frozen. vacuum_freeze_table_age
> and vacuum_multixact_freeze_table_age control when a table is
> aggressively vacuumed.
>
> +         </para>
> +        </listitem>
> +        <listitem>
> +         <para>
> +          <literal>failsafe</literal>: A vacuum operation that entered failsafe
> +          mode when the system was at risk of transaction ID or multixact ID
> +          wraparound (see <xref linkend="guc-vacuum-failsafe-age"/> and
> +          <xref linkend="guc-vacuum-multixact-failsafe-age"/>).
>
> failsafe: The operation has entered failsafe mode, in which vacuum
> performs only the minimum work needed to avoid transaction ID
> wraparound failure. vacuum_failsafe_age and
> vacuum_multixact_failsafe_age controls when the vacuum enters failsafe
> mode.

Fixed.

> +      </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?

> ---
> +       /* 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.


--
Best regards,
Shinya Kato
NTT OSS Center