Re: Refactoring backend fork+exec code - Mailing list pgsql-hackers
From | Heikki Linnakangas |
---|---|
Subject | Re: Refactoring backend fork+exec code |
Date | |
Msg-id | 8171f1aa-496f-46a6-afc3-c46fe7a9b407@iki.fi Whole thread Raw |
In response to | Re: Refactoring backend fork+exec code (Andres Freund <andres@anarazel.de>) |
Responses |
Re: Refactoring backend fork+exec code
|
List | pgsql-hackers |
On 22/01/2024 23:07, Andres Freund wrote: > On 2024-01-10 14:35:52 +0200, Heikki Linnakangas wrote: >> @@ -5344,31 +5344,31 @@ StartChildProcess(AuxProcType type) >> errno = save_errno; >> switch (type) >> { >> - case StartupProcess: >> + case B_STARTUP: >> ereport(LOG, >> (errmsg("could not fork startup process: %m"))); >> break; >> - case ArchiverProcess: >> + case B_ARCHIVER: >> ereport(LOG, >> (errmsg("could not fork archiver process: %m"))); >> break; >> - case BgWriterProcess: >> + case B_BG_WRITER: >> ereport(LOG, >> (errmsg("could not fork background writer process: %m"))); >> break; >> - case CheckpointerProcess: >> + case B_CHECKPOINTER: >> ereport(LOG, >> (errmsg("could not fork checkpointer process: %m"))); >> break; >> - case WalWriterProcess: >> + case B_WAL_WRITER: >> ereport(LOG, >> (errmsg("could not fork WAL writer process: %m"))); >> break; >> - case WalReceiverProcess: >> + case B_WAL_RECEIVER: >> ereport(LOG, >> (errmsg("could not fork WAL receiver process: %m"))); >> break; >> - case WalSummarizerProcess: >> + case B_WAL_SUMMARIZER: >> ereport(LOG, >> (errmsg("could not fork WAL summarizer process: %m"))); >> break; > > Seems we should replace this with something slightly more generic one of these > days... The later patches in this thread will turn these into ereport(LOG, (errmsg("could not fork %s process: %m", PostmasterChildName(type)))); >> diff --git a/src/backend/utils/activity/backend_status.c b/src/backend/utils/activity/backend_status.c >> index 1a1050c8da1..92f24db4e18 100644 >> --- a/src/backend/utils/activity/backend_status.c >> +++ b/src/backend/utils/activity/backend_status.c >> @@ -257,17 +257,16 @@ pgstat_beinit(void) >> else >> { >> /* Must be an auxiliary process */ >> - Assert(MyAuxProcType != NotAnAuxProcess); >> + Assert(IsAuxProcess(MyBackendType)); >> >> /* >> * Assign the MyBEEntry for an auxiliary process. Since it doesn't >> * have a BackendId, the slot is statically allocated based on the >> - * auxiliary process type (MyAuxProcType). Backends use slots indexed >> - * in the range from 0 to MaxBackends (exclusive), so we use >> - * MaxBackends + AuxProcType as the index of the slot for an auxiliary >> - * process. >> + * auxiliary process type. Backends use slots indexed in the range >> + * from 0 to MaxBackends (exclusive), and aux processes use the slots >> + * after that. >> */ >> - MyBEEntry = &BackendStatusArray[MaxBackends + MyAuxProcType]; >> + MyBEEntry = &BackendStatusArray[MaxBackends + MyBackendType - FIRST_AUX_PROC]; >> } > > Hm, this seems less than pretty. It's probably ok for now, but it seems like a > better fix might be to just start assigning backend ids to aux procs or switch > to indexing by pgprocno? Using pgprocno is a good idea. Come to think of it, why do we even have a concept of backend ID that's separate from pgprocno? backend ID is used to index the ProcState array, but AFAICS we could use pgprocno as the index to that, too. -- Heikki Linnakangas Neon (https://neon.tech)
pgsql-hackers by date: