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

From Ildus Kurbangaliev
Subject Re: [PATCH] Refactoring of LWLock tranches
Date
Msg-id 20151130134015.447b3e07@lp
Whole thread Raw
In response to Re: [PATCH] Refactoring of LWLock tranches  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, 23 Nov 2015 12:12:23 -0500
Robert Haas <robertmhaas@gmail.com> wrote:

> On Fri, Nov 20, 2015 at 6:53 AM, Ildus Kurbangaliev
> <i.kurbangaliev@postgrespro.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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Next
From: Michael Paquier
Date:
Subject: Re: Potential pointer dereference in plperl.c (caused by transforms patch)