Re: [PATCH] Refactoring of LWLock tranches

From: Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, 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-30 10:40:15
Message-ID: 20151130134015.447b3e07@lp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 23 Nov 2015 12:12:23 -0500
Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Fri, Nov 20, 2015 at 6:53 AM, Ildus Kurbangaliev
> <i(dot)kurbangaliev(at)postgrespro(dot)ru> wrote:
> > We keep limited number of LWLocks in base shared memory, why not
> > keep their thanches in shared memory too? Other tranches can be in
> > local memory, we just have to save somewhere highest id of these
> > tranches.
>
> I just don't see it buying us anything. The tranches are small and
> contain only a handful of values. The values need to be present in
> shared memory but the tranches themselves don't.
>
> Now, if it's convenient to put them in shared memory and doesn't cause
> us any other problems, then maybe there's no real downside. But it's
> not clear to me that there's any upside either.
>

I see. Since tranche names are always in shared memory or static
strings, then maybe we should just create global static char * array
with fixed length for names (something like `char
*LWLockTrancheNames[NUM_LWLOCK_BUILTIN_TRANCHES]`)? It will be
just enough for monitoring purposes, and doesn't matter where a tranche
is located. We will have a name pointer for built-in tranches only, and
fixed length of this array will not be a problem since we know exact
count of them.

--
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-11-30 12:33:51 Re: Potential pointer dereference in plperl.c (caused by transforms patch)
Previous Message Michael Paquier 2015-11-30 07:53:03 Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.