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

From andres@anarazel.de
Subject Re: [PATCH] Refactoring of LWLock tranches
Date
Msg-id 20151212181702.GH17938@alap3.anarazel.de
Whole thread Raw
In response to Re: [PATCH] Refactoring of LWLock tranches  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] Refactoring of LWLock tranches
List 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:
>
> http://www.postgresql.org/message-id/20150907175909.GD5084@alap3.anarazel.de
>
> 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.
http://archives.postgresql.org/message-id/20150915020625.GI9666%40alap3.anarazel.de
would alleviate that concern again, as it collapses flags, usage_count,
buf_hdr_lock and refcount into one 32 bit int...

Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?
Next
From: Petr Jelinek
Date:
Subject: Re: WIP: Rework access method interface