Re: [PATCH] Refactoring of LWLock tranches

From: "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>, 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-12-12 18:17:02
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2015-11-15 16:24:24 -0500, Robert Haas wrote:
> I think what we should do about the buffer locks is polish up this
> patch and get it applied:
> I think it needs to be adapted to use predefined constants for the
> tranche IDs instead of hardcoded values, maybe based on the attached
> tranche-constants.patch.

Here's two patches doing that. The first is an adaption of your
constants patch, using an enum and also converting xlog.c's locks. The
second is the separation into distinct tranches.

One thing to call out is that an "oversized" s_lock can now make
BufferDesc exceed 64 bytes, right now that's just the case when it's
larger than 4 bytes. I'm not sure if that's cause for real concern,
given that it's not very concurrent or ancient platforms where that's
the case.
would alleviate that concern again, as it collapses flags, usage_count,
buf_hdr_lock and refcount into one 32 bit int...


Andres Freund

Attachment Content-Type Size
0001-Define-enum-of-builtin-LWLock-tranches.patch text/x-patch 4.6 KB
0002-Move-buffer-LWLocks-out-of-the-main-array-and-increa.patch text/x-patch 18.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2015-12-12 18:21:04 Re: WIP: Rework access method interface
Previous Message Corey Huinker 2015-12-12 17:48:37 Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?