On Mon, Mar 6, 2017 at 1:37 PM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> Ok, I think I understand the complete picture.
>
> At Mon, 06 Mar 2017 15:58:56 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote
in<20170306.155856.198084190.horiguchi.kyotaro@lab.ntt.co.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.
>
In RegisterLWLockTranches(), we do register the named tranches as well
which should make it available in LWLockTrancheArray. Do you see any
reason why that shouldn't work?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
