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
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. |