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

Hi,

On 2021-10-14 17:28:34 +0900, Kyotaro Horiguchi wrote:
> 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.

FWIW, I don't actually think there's necessarily that strong a need for
density in sinvaladt. With a few relatively changes we can get rid of the O(n)
work in the most crucial paths.

In https://www.postgresql.org/message-id/20210802171255.k4yv5cfqaqbuuy6f%40alap3.anarazel.de
I wrote:
> Another approach to deal with this could be to simply not do the O(n) work in
> SIInsertDataEntries(). It's not obvious that ->hasMessages is actually
> necessary - we could atomically read maxMsgNum without acquiring a lock
> instead of needing the per-backend ->hasMessages. I don't the density would
> be a relevant factor in SICleanupQueue().

This'd get rid of the need of density *and* make SIInsertDataEntries()
cheaper.

Greetings,

Andres Freund