On Mon, Mar 6, 2017 at 1:37 PM, Kyotaro HORIGUCHI <horiguchi.kyot...@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.kyot...@lab.ntt.co.jp> wrote in > <20170306.155856.198084190.horiguchi.kyot...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
