Re: [PATCH] Refactoring of LWLock tranches - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] Refactoring of LWLock tranches
Date
Msg-id CA+TgmoZCzaLOSjfRjuhNF-ZdMTi2kGJyvDE_VXEYaK1q-S_PoQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Refactoring of LWLock tranches  (Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>)
Responses Re: [PATCH] Refactoring of LWLock tranches  (Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>)
List pgsql-hackers
On Fri, Nov 6, 2015 at 6:27 AM, Ildus Kurbangaliev
<i.kurbangaliev@postgrespro.ru> wrote:
> There is a patch that splits SLRU LWLocks to separate tranches and
> moves them to SLRU Ctl. It does some work from the main patch from
> this thread, but can be commited separately. It also simplifies
> lwlock.c.

Thanks.  I like the direction this is going.

-               char       *ptr;
-               Size            offset;
-               int                     slotno;
+               char            *ptr;
+               Size             offset;
+               int              slotno;
+               int              tranche_id;
+               LWLockPadded    *locks;

Please don't introduce this kind of churn.  pgindent will undo it.

This isn't going to work for EXEC_BACKEND builds, I think.  It seems
to rely on the LWLockRegisterTranche() performed !IsUnderPostmaster
being inherited by subsequent children, which won't work under
EXEC_BACKEND.  Instead, store the tranche ID in SlruSharedData.  Move
the LWLockRegisterTranche call out from the (!IsUnderPostmaster) case
and call it based on the tranche ID from SlruSharedData.

I would just drop the add_postfix stuff.  I think it's fine if the
names of the shared memory checks are just "CLOG" etc. rather than
"CLOG Slru Ctl", and similarly I think the locks can be registered
without the "Locks" suffix.  It'll be clear from context that they are
locks.  I suggest also that we just change all of these names to be
lower case, though I realize that's a debatable and cosmetic point.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Adrian Vondendriesch
Date:
Subject: Re: [BUGS] BUG #12989: pg_size_pretty with negative values
Next
From: Robert Haas
Date:
Subject: Re: [BUGS] BUG #12989: pg_size_pretty with negative values