Re: Add "io worker" as backend_type to the pg_stat_activity documentation

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