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
