Re: [PATCH] Refactoring of LWLock tranches

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: [PATCH] Refactoring of LWLock tranches
Date: 2015-11-06 17:53:18
Message-ID: CA+TgmoZCzaLOSjfRjuhNF-ZdMTi2kGJyvDE_VXEYaK1q-S_PoQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 6, 2015 at 6:27 AM, Ildus Kurbangaliev
<i(dot)kurbangaliev(at)postgrespro(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-11-06 17:53:56 Re: [BUGS] BUG #12989: pg_size_pretty with negative values
Previous Message Adrian Vondendriesch 2015-11-06 17:44:36 Re: [HACKERS] BUG #12989: pg_size_pretty with negative values