Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit()
От | Bharath Rupireddy |
---|---|
Тема | Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit() |
Дата | |
Msg-id | CALj2ACVBew2T9=+tT2ThmYxQ8igrS6VL_PF8aKrSK3c9yMqc4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit() (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit()
|
Список | pgsql-hackers |
On Tue, Oct 12, 2021 at 2:03 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > [1] - https://www.postgresql.org/message-id/CALj2ACXZ_o7rcOb7-Rs96P0d%3DEi%2Bnvf_WZ-Meky7Vv%2BnQNFYjQ%40mail.gmail.com > > The patch does this: > > case StartupProcess: > + MyBackendId = MaxBackends + MyAuxProcType + 1; > > as well as this: > > + shmInvalBuffer->maxBackends = MaxBackends + 1; > > These don't seem to be in the strict correspondence. I'd prefer > something like the following. > > + /* currently only StartupProcess uses nailed SI slot */ > + shmInvalBuffer->maxBackends = MaxBackends + StartupProcess + 1; I don't think it is a good idea to use macro StartupProcess (because the macro might get changed to a different value later). What we essentially need to do for procState array is to extend its size by 1 (for startup process) which is being handled separately in [1]. Once the patch at [1] gets in, the patch proposed here will not have the above change at all. [1] - https://www.postgresql.org/message-id/CALj2ACXZ_o7rcOb7-Rs96P0d%3DEi%2Bnvf_WZ-Meky7Vv%2BnQNFYjQ%40mail.gmail.com Regards, Bharath Rupireddy.
В списке pgsql-hackers по дате отправления: