Auxiliary Processes and MyAuxProc

From: Mike Palmiotto <mike(dot)palmiotto(at)crunchydata(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Auxiliary Processes and MyAuxProc
Date: 2019-02-25 17:58:03
Message-ID: CAMN686FE0OdZKp9YPO=htC6LnA6aW4r-+jq=3Q5RAoFQgW8EtA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

I've been looking through the startup code for postmaster forks and
saw a couple of mechanisms used. Most forks seem to be using
StartChildProcess with a MyAuxProc emumerator, but then some
(autovacuum launcher/worker, syslogger, bgworker, archiver) are forked
through their own start functions.

I noticed some implication in the pgsql-hackers archives [1] that
non-AuxProcs are as such because they don't need access to shared
memory. Is this an accurate explanation?

For some context, I'm trying to come up with a patch to set the
process identifier (MyAuxProc/am_autovacuumworker/launcher,
am_archiver, etc.) immediately after forking, so we can provide
process context info to a hook in early startup. I wanted to make sure
to do things as cleanly as possible.

With the current startup architecture, we have to touch multiple
entrypoints to achieve the desired effect. Is there any particular
reason we couldn't fold all of the startup processes into the
StartChildProcess code and assign MyAuxProc for processes that don't
currently have one, or is this a non-starter?

Thank you for your time.

--
Mike Palmiotto
Software Engineer
Crunchy Data Solutions
https://crunchydata.com

[1] https://www.postgresql.org/message-id/20181127.175949.06807946.horiguchi.kyotaro%40lab.ntt.co.jp

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-02-25 18:02:03 Re: POC: converting Lists into arrays
Previous Message Fujii Masao 2019-02-25 17:50:26 Re: Remove Deprecated Exclusive Backup Mode