On Wed, Oct 6, 2021 at 5:10 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Oct 05, 2021 at 12:16:06PM -0400, Robert Haas wrote:
> > Perhaps that's so, but it doesn't seem like a good reason not to make
> > them more responsive.
>
> Yeah, that's still some information that the user asked for. Looking
> at the things that have a PGPROC entry, should we worry about the main
> loop of the logical replication launcher?
IMHO, we can support all the processes which return a PGPROC entry by
both BackendPidGetProc and AuxiliaryPidGetProc where the
AuxiliaryPidGetProc would cover the following processes. I'm not sure
one is interested in the memory context info of auxiliary processes.
/*
* We set aside some extra PGPROC structures for auxiliary processes,
* ie things that aren't full-fledged backends but need shmem access.
*
* Background writer, checkpointer, WAL writer and archiver run during normal
* operation. Startup process and WAL receiver also consume 2 slots, but WAL
* writer is launched only after startup has exited, so we only need 5 slots.
*/
#define NUM_AUXILIARY_PROCS 5
Regards,
Bharath Rupireddy.
