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
