Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit()

On Mon, Oct 11, 2021 at 8:59 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>
> On 2021/10/11 19:46, Bharath Rupireddy wrote:
> > If we do the above, then the problem might arise if somebody calls
> > SICleanupQueue and wants to signal the startup process, the below code
> > (from SICleanupQueue) can't get the startup process backend id. So,
> > the backend id calculation for the startup process can't just be
> > MaxBackends + MyAuxProcType + 1.
> > BackendId his_backendId = (needSig - &segP->procState[0]) + 1;
>
> Attached POC patch illustrates what I'm in mind. ISTM this change
> doesn't prevent SICleanupQueue() from getting right backend ID
> of the startup process. Thought?

I will take a look at it a bit later.

> > It looks like we need to increase the size of the ProcState array by 1
> > at least (for the startup process). Currently the ProcState array
> > doesn't have entries for auxiliary processes, it does have entries for
> > MaxBackends. The startup process is eating up one slot from
> > MaxBackends. Since we need only an extra ProcState array slot for the
> > startup process I think we could just extend its size by 1. Instead of
> > modifying the MaxBackends definition, we can just add 1 (and a comment
> > saying this 1 is for startup process) to shmInvalBuffer->maxBackends
> > in SInvalShmemSize, CreateSharedInvalidationState. IMO, this has to go
> > in a separate patch and probably in a separate thread. Thoughts?
>
> Agreed.

Posted a patch in a separate thread, please review it.
https://www.postgresql.org/message-id/CALj2ACXZ_o7rcOb7-Rs96P0d%3DEi%2Bnvf_WZ-Meky7Vv%2BnQNFYjQ%40mail.gmail.com

Regards,
Bharath Rupireddy.