On Wed, 8 Jul 2026 at 18:43, Heikki Linnakangas
<[email protected]> wrote:
>
> Refactor how some aux processes advertise their ProcNumber
>
> This moves the responsibility of setting the ProcGlobal->walwriterProc
> and checkpointerProc fields into InitAuxiliaryProcess. Also switch to
> the same pattern to advertise the autovacuum launcher's ProcNumber,
> replacing the ad hoc av_launcherpid field in shared memory. This can
> easily be extended to other aux processes in the future, if other
> processes need to find them.
>
> Switch to pg_atomic_uint32 for the fields. Seems easier to reason
> about than volatile pointers. There was some precedence for that, as
> were already using pg_atomic_uint32 for the procArrayGroupFirst and
> clogGroupFirst fields, which also store ProcNumbers.
>
> Todo: We could also replace WalRecv->procno with this, but that's a
> little more code churn so I left that for the future.
>
> Reviewed-by: Andres Freund <[email protected]>
> Discussion: 
> https://www.postgresql.org/message-id/[email protected]
>
> Branch
> ------
> master
>
> Details
> -------
> https://git.postgresql.org/pg/commitdiff/842169b6c110f48c9f7a2dc29d0cedcc97c2ff29
>
> Modified Files
> --------------
> src/backend/access/transam/xlog.c     |  3 +--
> src/backend/postmaster/autovacuum.c   | 19 ++++++++++---------
> src/backend/postmaster/checkpointer.c | 14 ++++----------
> src/backend/postmaster/walwriter.c    |  6 ------
> src/backend/storage/lmgr/proc.c       | 32 ++++++++++++++++++++++++++++++--
> src/include/storage/proc.h            |  7 ++++---
> 6 files changed, 49 insertions(+), 32 deletions(-)

@@ -724,6 +725,14 @@ InitAuxiliaryProcess(void)
     */
    PGSemaphoreReset(MyProc->sem);

+   /* Some aux processes are also advertised in ProcGlobal */
+   if (MyBackendType == B_AUTOVAC_LAUNCHER)
+       pg_atomic_write_u32(&ProcGlobal->avLauncherProc, MyProcNumber);

I'm looking for the places this gets called from. I can only see
auxprocess.c which the launcher doesn't go through. The same question
for similar code in AuxiliaryProcKill().

Thom


Reply via email to