Re: [PATCH] Refactoring of LWLock tranches

From: Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>
To: "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: [PATCH] Refactoring of LWLock tranches
Date: 2015-09-06 19:57:04
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On Sep 6, 2015, at 2:36 PM, andres(at)anarazel(dot)de wrote:
> On 2015-09-05 12:48:12 +0300, Ildus Kurbangaliev wrote:
>> Another parts require a some discussion so I didn't touch them yet.
> At this point I don't see any point in further review until these are
> addressed.
>> The idea to create an individual tranches for individual LWLocks have
>> come from Heikki Linnakangas and I also think that tranche is a good place to keep
>> LWLock name.
> I think it's rather ugly.
>> Base of these tranches points to MainLWLockArray
> And that's just plain wrong. The base of a tranche ought to point to the
> first lwlock in it.

Ok, I've kept only one tranche for individual LWLocks

> On Sep 2, 2015, at 1:43 AM, andres(at)anarazel(dot)de wrote:
> I don't really like the tranche model as in the patch right now. I'd
> rather have in a way that we have one tranch for all the individual
> lwlocks, where the tranche points to an array of names alongside the
> tranche's name. And then for the others we just supply the tranche name,
> but leave the name array empty, whereas a name can be generated.

Maybe I don't understand something here, but why add extra field to all tranches
if we need only one array (especially the array for individual LWLocks).

Ildus Kurbangaliev
Postgres Professional: <>
The Russian Postgres Company

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message 2015-09-06 21:18:02 Re: [PATCH] Refactoring of LWLock tranches
Previous Message Joe Conway 2015-09-06 19:34:28 Re: exposing pg_controldata and pg_config as functions