Hi, I just tried to add a, seemingly innocuous, assertion to ProcArrayAdd()/Remove() that proc->pgprocno is < arrayP->maxProcs. That quickly fails.
The reason for that is that PGPROC are created in the following order 1) MaxBackends normal (*[1]) backends 2) NUM_AUXILIARY_PROCS auxiliary processes 3) max_prepared_xacts prepared transactions. and pgprocnos are assigned sequentially - they are needed to index into ProcGlobal->allProcs. In contrast to that procarray.c initializes maxProcs to #define PROCARRAY_MAXPROCS (MaxBackends + max_prepared_xacts) i.e. without the aux processes. Which means that some of the prepared transactions have pgprocnos that are bigger than ProcArrayStruct->maxProcs. Hence my assertion failure. This is obviously not a bug, but is quite hard to understand / confusing. I think I made a similar mistake before. I'd at least like to add a comment with a warning somewhere in ProcArrayStruct or such. An alternative approach would be to change the PGPROC order to instead be 1) aux, b) normal backends, 3) prepared xacts and give aux processes a negative or invalid pgprocno. One small advantage of that would be that we'd not need to "skip" over the "aux process hole" between normal and prepared xact PGPROCs in various procarray.c routines that iterate over procs. Greetings, Andres Freund [1] well, kinda. It's user backends followed by autovacuum worker, launcher, worker processes and wal senders.