Re: pgsql: Refactor how some aux processes advertise their ProcNumber - Mailing list pgsql-committers

From Álvaro Herrera
Subject Re: pgsql: Refactor how some aux processes advertise their ProcNumber
Date
Msg-id ak-StP_W7iUXEKxl@alvherre.pgsql
Whole thread
In response to Re: pgsql: Refactor how some aux processes advertise their ProcNumber  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-committers
On 2026-Jul-09, Heikki Linnakangas wrote:

> Why is the autovacuum launcher not an aux process? I guess it's because it
> needs to acquire a heavy-weight lock in order to read the list of databases.

Because it scans pg_database.

commit 00e6a16d01683762c2f34eb4909fc739093ab3bf
Author:     Tom Lane <tgl@sss.pgh.pa.us> []
AuthorDate: Mon Aug 31 19:41:00 2009 +0000
CommitDate: Mon Aug 31 19:41:00 2009 +0000

    Change the autovacuum launcher to read pg_database directly, rather than
    via the "flat files" facility.  This requires making it enough like a backend
    to be able to run transactions; it's no longer an "auxiliary process" but
    more like the autovacuum worker processes.  Also, its signal handling has
    to be brought into line with backends/workers.  In particular, since it
    now has to handle procsignal.c processing, the special autovac-launcher-only
    signal conditions are moved to SIGUSR2.
    
    Alvaro, with some cleanup from Tom

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"If you want to have good ideas, you must have many ideas.  Most of them
will be wrong, and what you have to learn is which ones to throw away."
                                                         (Linus Pauling)



pgsql-committers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pgsql: Refactor how some aux processes advertise their ProcNumber
Next
From: Heikki Linnakangas
Date:
Subject: pgsql: libpq: Make error checks in the new buffer draining code more ro