Re: [BUG FIX] Removing NamedLWLockTrancheArray

By the way,

At Mon, 06 Mar 2017 17:07:55 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20170306(dot)170755(dot)68410634(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> Ok, I think I understand the complete picture.
>
> At Mon, 06 Mar 2017 15:58:56 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20170306(dot)155856(dot)198084190(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> > > I can guess two ways to fix this. One is change the definition of
> > > T_NAME.
> > >
> > > | #define T_NAME(l) \
> > > | ((l)->tranche < LWTRANCHE_FIRST_USER_DEFINED ? \
> > > | LWLockTrancheArray[(l)->tranche] : \
> > > | NamedLWLockTrancheArray[(l)->tranche - LWTRANCHE_FIRST_USER_DEFINED]
> > >
> > > It makes the patch small but I don't thing the shape is
> > > desirable.
> > >
> > > Then, the other way is registering named tranches into the main
> > > tranche array. The number and names of the requested named
> > > tranches are known to postmaster so they can be allocated and
> > > initialized at the time.
> > >
> > > The mapping of the shared memory is inherited to backends so
> > > pointing to the addresses in shared memory will work in the
> > > !EXEC_BACKEND case. I confirmed that the behavior is ensured also
> > > in EXEC_BACKEND case.
>
> But this doesn't work for
> LWLockNewTrancheId/LWLockRegisterTranche and it is valuable
> interface. So the measure we can take is redefining T_NAME.

I realized that *I* have used the interface
RequestNamedLWLockTranche in certain extensions but I completely
forgot that and faintly recalled after being pointed by one of my
colleagues..

Sorry for the off-topic.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center