From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit() |
Date: | 2021-10-12 09:27:58 |
Message-ID: | CALj2ACVBew2T9=+tT2ThmYxQ8igrS6VL_PF8aKrSK3c9yMqc4A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 12, 2021 at 2:03 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > [1] - /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] - /message-id/CALj2ACXZ_o7rcOb7-Rs96P0d%3DEi%2Bnvf_WZ-Meky7Vv%2BnQNFYjQ%40mail.gmail.com
Regards,
Bharath Rupireddy.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Lepikhov | 2021-10-12 10:00:54 | Re: Make query ID more portable |
Previous Message | Andres Freund | 2021-10-12 09:08:29 | Re: [RFC] building postgres with meson |