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. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
diff --git a/src/backend/storage/lmgr/lwlock.c b/src/backend/storage/lmgr/lwlock.c index ab81d94..7c4c8f4 100644 --- a/src/backend/storage/lmgr/lwlock.c +++ b/src/backend/storage/lmgr/lwlock.c @@ -115,7 +115,9 @@ static char **LWLockTrancheArray = NULL; static int LWLockTranchesAllocated = 0; #define T_NAME(lock) \ - (LWLockTrancheArray[(lock)->tranche]) + ((lock)->tranche < LWTRANCHE_FIRST_USER_DEFINED ? \ + LWLockTrancheArray[(lock)->tranche] : \ + NamedLWLockTrancheArray[(lock)->tranche - LWTRANCHE_FIRST_USER_DEFINED].trancheName) /* * This points to the main array of LWLocks in shared memory. Backends inherit
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
