Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit() - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit()
Date
Msg-id 20211013.195252.1965983915421931723.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit()  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit()
List pgsql-hackers
At Wed, 13 Oct 2021 13:39:24 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in 
> On Wed, Oct 13, 2021 at 4:25 AM Andres Freund <andres@anarazel.de> wrote:
> >
> > Hi,
> >
> > On 2021-10-11 15:24:46 +0900, Fujii Masao wrote:
> > > How about modifying SharedInvalBackendInit() so that it accepts
> > > BackendId as an argument and allocates the ProcState entry of
> > > the specified BackendId? That is, the startup process determines
> > > that its BackendId is "MaxBackends + MyAuxProcType (=StartupProcess) + 1"
> > > in AuxiliaryProcessMain(), and then it passes that BackendId to
> > > SharedInvalBackendInit() in InitRecoveryTransactionEnvironment().
> >
> > If I understand correctly what you're proposing, I think that's going in the
> > wrong direction. We should work towards getting rid of BackendIds
> > instead. This whole complication vanishes if we make sinvaladt use pgprocno.
> >
> > See https://postgr.es/m/20210802171255.k4yv5cfqaqbuuy6f%40alap3.anarazel.de
> > for some discussion of this.

I feel this is the right direction. I understand sinvaladt needs the
backend id but I think it's wrong that the backend id is used widely.
And, in the current direction, procState array gets very sparse and
performence of sinval gets degraded.

> Will any of the backends get pgprocno greater than MaxBackends? The
> pgprocno can range from 0 to ((MaxBackends + NUM_AUXILIARY_PROCS +
> max_prepared_xacts) - 1) and the ProcState array size is MaxBackends.
> How do we put a backend with pgprocno > MaxBackends, into the
> ProcState array? Is it that we also increase ProcState array size to
> (MaxBackends + NUM_AUXILIARY_PROCS + max_prepared_xacts)? Probably
> this is the dumbest thing as some slots are unused
> (NUM_AUXILIARY_PROCS - 1 + max_prepared_xacts slots. -1 because the
> startup process needs a ProcState slot) and the shared memory is
> wasted.

The elements for max_prepared_xacts can be placed at the last part of
pgprocno and we can actually omit allocating memory for them.  I don't
think NUM_AUXILIARY_PROC is that large. It's only 5 and won't increase
much in future.  Since we know that startup is the only user of
procsig, we can save the space for four of them.  In short, no extra
memory is required by using pgprocno for now.

The actual problem is if we simply use pgprocno in sinvaladt, we will
see preformance degradation caused by the super sparse procState
array.  As Andres mentioned in the URL above, it can be avoided if we
can get rid of looping over the array.

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.

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.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Next Steps with Hash Indexes
Next
From: Ajin Cherian
Date:
Subject: Re: row filtering for logical replication