Add "io worker" as backend_type to the pg_stat_activity documentation

On Tue, Jul 21, 2026 at 09:58:34AM +0200, Laurenz Albe wrote:

I happened to notice that "io worker" was missing in the list of
backend types in the pg_stat_activity documentation.

Right.

Here is a patch to fix that.

I wondered vaguely if the list should be sorted alphabetically,
but didn't do it a) to keep the patch easy to read and
b) because the list is not long enough for readers to get lost.

And here I just thought while looking at this section of the docs that
the list is super long, and that we could reshape it the same way as
"state" for the possible values, sorting it on the way.
--
Michael

On Tue, 2026-07-21 at 17:02 +0900, Michael Paquier wrote:

On Tue, Jul 21, 2026 at 09:58:34AM +0200, Laurenz Albe wrote:

I happened to notice that "io worker" was missing in the list of
backend types in the pg_stat_activity documentation.

Right.

I wondered vaguely if the list should be sorted alphabetically,
but didn't do it a) to keep the patch easy to read and
b) because the list is not long enough for readers to get lost.

And here I just thought while looking at this section of the docs that
the list is super long, and that we could reshape it the same way as
"state" for the possible values, sorting it on the way.

Ok, here is a patch with the list sorted alphabetically and
converted into an itemiized list.

Yours,
Laurenz Albe

On Tue, Jul 21, 2026 at 6:59 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:

On Tue, 2026-07-21 at 17:02 +0900, Michael Paquier wrote:

On Tue, Jul 21, 2026 at 09:58:34AM +0200, Laurenz Albe wrote:

I happened to notice that "io worker" was missing in the list of
backend types in the pg_stat_activity documentation.

Right.

Isn't it better to add the other missing process names as well, such as
slotsync worker, data checksums launcher, data checksums worker, and
REPACK decoding worker?

Also, the current list says "logical replication worker", but that isn't
an actual process name. It refers to four different worker types:
logical replication apply worker, logical replication parallel worker,
logical replication sequence synchronization worker, and logical replication
table synchronization worker. Isn't it better to list those actual
process names instead?

Regards,

--
Fujii Masao

On Wed, 2026-07-22 at 01:48 +0900, Fujii Masao wrote:

On Tue, Jul 21, 2026 at 09:58:34AM +0200, Laurenz Albe wrote:

I happened to notice that "io worker" was missing in the list of
backend types in the pg_stat_activity documentation.

Isn't it better to add the other missing process names as well, such as
slotsync worker, data checksums launcher, data checksums worker, and
REPACK decoding worker?

Also, the current list says "logical replication worker", but that isn't
an actual process name. It refers to four different worker types:
logical replication apply worker, logical replication parallel worker,
logical replication sequence synchronization worker, and logical replication
table synchronization worker. Isn't it better to list those actual
process names instead?

You are right. Here is patch v3 with a completed list; I hope I didn't
forget anything.

Yours,
Laurenz Albe

On Tue, Jul 21, 2026 at 09:04:15PM +0200, Laurenz Albe wrote:

You are right. Here is patch v3 with a completed list; I hope I didn't
forget anything.

I am counting 23 entries. I don't see anything forgotten on top of my
mind, and we are indeed missing a lot of new entries.. I feel that
like everybody who has added a new worker in the backend has forgotten
to update this list.

While on it, I also feel like we may have some holes with
log_min_messages and the new process_type. At least a bunch of them
are missing.. I'll ping that fact on a new thread. No need to worry
about that here.

+         <para>
+          <literal>autovacuum worker</literal>: A background process running
+          <command>VACUUM</command> or <command>ANALYZE</command> on a single
+          table.
+         </para>

Also active when autovacuum = on?

+         <para>
+          <literal>walreceiver</literal>: The background process that receives
+          WAL records from a WAL sender, active in streaming replication
+          standby mode.
+         </para>

We can only have one of these.

+        </listitem>
+        <listitem>
+         <para>
+          <literal>walsender</literal>: A background process that sends WAL
+          records to receivers (during streaming replication) or decodes WAL
+          and sends the decoded information (during logical replication).
+         </para>
+        </listitem>

No mention of the max_wal_senders dependency? Perhaps not worth
mentioning, still..
--
Michael

On Wed, 2026-07-22 at 07:18 +0900, Michael Paquier wrote:

On Tue, Jul 21, 2026 at 09:04:15PM +0200, Laurenz Albe wrote:

You are right. Here is patch v3 with a completed list; I hope I didn't
forget anything.

I am counting 23 entries. I don't see anything forgotten on top of my
mind, and we are indeed missing a lot of new entries.

Great.

+         <para>
+          <literal>autovacuum worker</literal>: A background process running
+          <command>VACUUM</command> or <command>ANALYZE</command> on a single
+          table.
+         </para>

Also active when autovacuum = on?

Well, anti-wraparound autovacuum workers can also run if autovacuum = off.
Also, autovacuum workers only indirectly depend on the GUC.
I figured that if I say that the autovacuum launcher depends on the GUC and
launches autovacuum workers, the indirect dependency should be obvious.

+         <para>
+          <literal>walreceiver</literal>: The background process that receives
+          WAL records from a WAL sender, active in streaming replication
+          standby mode.
+         </para>

We can only have one of these.

That's why I said "*the* background process".
Or did I miss your point?

+        </listitem>
+        <listitem>
+         <para>
+          <literal>walsender</literal>: A background process that sends WAL
+          records to receivers (during streaming replication) or decodes WAL
+          and sends the decoded information (during logical replication).
+         </para>
+        </listitem>

No mention of the max_wal_senders dependency? Perhaps not worth
mentioning, still..

I don't want to mention all GUCs that have an influence on the processes,
and I feel that my descriptions are already pretty long.

If I mention that dependency, I should also mention that max_connections
limits the number of backends, and so on...

Yours,
Laurenz Albe

On Wed, Jul 22, 2026 at 07:36:14AM +0200, Laurenz Albe wrote:

launches autovacuum workers, the indirect dependency should be
obvious.

Okay.

That's why I said "*the* background process".
Or did I miss your point?

No, I have managed to miss the "the".

If I mention that dependency, I should also mention that max_connections
limits the number of backends, and so on...

Okay by me.
--
Michael

On Wed, Jul 22, 2026 at 7:18 AM Michael Paquier <michael@paquier.xyz> wrote:

On Tue, Jul 21, 2026 at 09:04:15PM +0200, Laurenz Albe wrote:

You are right. Here is patch v3 with a completed list; I hope I didn't
forget anything.

I am counting 23 entries. I don't see anything forgotten on top of my
mind,

+1

Also a couple of minor comments:

+          <literal>archiver</literal>: The WAL archiver, active when
+          <xref linkend="guc-archive-mode"/> is <literal>on</literal>.

The archiver is also active when archive_mode = always. So isn't it better
to say "active when archive_mode is enabled" (as in the Glossary), or
"when archive_mode is on or always"?

+          <literal>logical replication launcher</literal>: The background
+          process that launches logical replication worker processes for
+          subscriptions.
+         </para>
+        </listitem>
+        <listitem>
+         <para>
+          <literal>logical replication apply worker</literal>: A background
+          process that applies data modifications on a logical subscriber.

If these entries are meant to be in alphabetical order, shouldn't
"logical replication apply worker" come before "logical replication launcher"?

Regards,

--
Fujii Masao

On Wed, 2026-07-22 at 18:34 +0900, Fujii Masao wrote:

a couple of minor comments:

+          <literal>archiver</literal>: The WAL archiver, active when
+          <xref linkend="guc-archive-mode"/> is <literal>on</literal>.

The archiver is also active when archive_mode = always. So isn't it better
to say "active when archive_mode is enabled" (as in the Glossary), or
"when archive_mode is on or always"?

True. I went with "enabled".

+          <literal>logical replication launcher</literal>: The background
+          process that launches logical replication worker processes for
+          subscriptions.
+         </para>
+        </listitem>
+        <listitem>
+         <para>
+          <literal>logical replication apply worker</literal>: A background
+          process that applies data modifications on a logical subscriber.

If these entries are meant to be in alphabetical order, shouldn't
"logical replication apply worker" come before "logical replication launcher"?

I must have picked the wrong collation :^/

v4 is attached.

Yours,
Laurenz Albe

On Wed, Jul 22, 2026 at 12:22:23PM +0200, Laurenz Albe wrote:

v4 is attached.

This one looks pretty clean after double-checking, so applied on HEAD.
Thanks.
--
Michael

On Thu, 2026-07-23 at 16:23 +0900, Michael Paquier wrote:

This one looks pretty clean after double-checking, so applied on HEAD.

Thanks for the review and the commit.

Laurenz Albe