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

From Yu Wang
Subject Re: Add mode column to pg_stat_progress_vacuum
Date
Msg-id 7bbb50c8-f865-4e75-bf8b-a0e54fd564c0@163.com
Whole thread Raw
In response to Re: Add mode column to pg_stat_progress_vacuum  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Add mode column to pg_stat_progress_vacuum
List pgsql-hackers
On 12/9/25 5:25 AM, Masahiko Sawada wrote:
> On Thu, Dec 4, 2025 at 8:30 PM Shinya Kato <shinya11.kato@gmail.com> wrote:
>> Thank you for the review!
>>
>> On Thu, Dec 4, 2025 at 9:15 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>>> I've attached a small change to simplify the 0001 patch. Please review it.
>> LGTM, and I've updated in v9 patches.
>>
>>> Here are a few comments:
>>>
>>> +        <listitem>
>>> +         <para>
>>> +          <literal>manual</literal>: The analyze was started by an explicit
>>>
>>> For consistency with "started_by" in pg_stat_progress_vacuum, I think
>>> it's better to start with "The operation was started by".
>> I think "started_by" in pg_stat_progress_vacuum uses "The vacuum was
>> started by ...".
> I missed that, you're right.
>
>>> ---
>>> +          <command>ANALYZE</command> or <command>VACUUM (ANALYZE)</command>
>>> +          command.
>>>
>>> How about using "... or VACUUM with the ANALYZE option"?
>> Agreed, I've fixed it.
> Thank you for updating the patch!
>
> The patches look good to me, so I'm going to push them if there are
> not further review comments and objections.
>
> Regards,
>
Hi,
I have a few additional suggestions that might be worth considering.

1.v9-0001
...
@@ -1018,8 +1018,11 @@ analyze threshold = analyze base threshold + 
analyze scale factor * number of tu
      see <xref linkend="table-lock-compatibility"/>. However, if the 
autovacuum
      is running to prevent transaction ID wraparound (i.e., the 
autovacuum query
      name in the <structname>pg_stat_activity</structname> view ends with
-    <literal>(to prevent wraparound)</literal>), the autovacuum is not
-    automatically interrupted.
+    <literal>(to prevent wraparound)</literal> or the
+    <literal>autovacuum_wraparound</literal> value in the
+    <structfield>started_by</structfield> column in the
+    <structname>pg_stat_progress_vacuum</structname> view), the 
autovacuum is
+    not automatically interrupted.
     </para>
...
The new "or" statement does not follow the structure of the previous 
sentence. The earlier sentence uses the pattern "ends with (to prevent 
wraparound)." However, the "or" statement lacks a similar structure such 
as "ends with." A suggested rephrasing is: or if 
pg_stat_progress_vacuum.started_by is 'autovacuum_wraparound'

2.v9-0001
...
+        <listitem>
+         <para>
+          <literal>normal</literal>: The operation is performing a standard
+          vacuum. It is neither required to run in aggressive mode nor 
operating
+          in failsafe mode.
+         </para>
+        </listitem>
...
Aggressive and failsafe are the other two modes explained later. 
Therefore, the sentence "It is neither required to run in aggressive 
mode nor operating in failsafe mode" is unnecessary and should be deleted.

3.v9-0002
...
+         <para>
+          <literal>manual</literal>: The analyze was started by an explicit
+          <command>ANALYZE</command> or <command>VACUUM</command> with the
+          <option>ANALYZE</option> option.
+         </para>
...

The current phrasing may lead to the misunderstanding that the "ANALYZE" 
option applies to both commands. It is recommended to revise it as: The 
analyze was started by an explicit <command>ANALYZE</command> command, 
or by <command>VACUUM (ANALYZE)</command>.

regards
--
Yu Wang




pgsql-hackers by date:

Previous
From: Kirill Reshke
Date:
Subject: Re: citext_1.out, citext.out confusing comment
Next
From: Chao Li
Date:
Subject: Re: commented out code