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

At Wed, 13 Oct 2021 19:52:52 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> Although needing a bit of care for the difference of invalid values
> for both though, BackendId can be easily replaced with pgprocno almost
> mechanically except sinvaladt. Therefore, we can confine the current
> backend ID within sinvaladt isolating from other part. The ids
> dedicated for sinvaladt can be packed to small range and perfomance
> won't be damaged.

Since I said it "mechanically doable", did I that. FWIW the attached is that. All behavioral differences come from the difrence of the valid range nad the invaild value between old BackendId and pgprpcno.

- Only sinvaladt uses the packed old backendid internally.
So procsignal can be sent to auxiliary processes.

- All other part uses pgprocno but it is named as backendid so as to
reduce the diff size.

- vxid's backendid part start from 0 not 1, and invalid backendid
becomes -1 to PG_INT32_MAX. Since it is mere a cosmetic issue, we
can replace PG_INT32_MAX as -1 on printing.

- The name of an exported snapshot changes. The first part start from
0, not 1.

- Prepared transactions' vxid is changed so that it's backendid part
has a valid value. Previously it was invalid id (-1). I'm not sure
it doesn't harm but I faced no trouble with make check-world.
(MarkAsPreparingGuts)

- With only 0002, backendid starts from 99 (when max_connection is
100) then decremented to 0, which is quite odd. 0001 reverses the
order of freelist.

> In the future, if we can get rid of looping over the procState array,
> sinvaladt - the last user of the current backend ID - can move to
> pgprocno and we will say good-bye to the current backend ID.

The attached files are named as *.txt so that bots don't recognize
them as a patch.

--
Kyotaro Horiguchi
NTT Open Source Software Center