From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | amit(dot)kapila16(at)gmail(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [BUG FIX] Removing NamedLWLockTrancheArray |
Date: | 2017-03-06 08:07:55 |
Message-ID: | 20170306.170755.68410634.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
fix_tranche_name_access.patch | text/x-patch | 632 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2017-03-06 08:16:09 | Re: Radix tree for character conversion |
Previous Message | Amit Langote | 2017-03-06 08:06:11 | pg_dump segfaults with publication |