Re: [PATCH] Refactoring of LWLock tranches

Поиск
Список
Период
Сортировка
От andres@anarazel.de
Тема Re: [PATCH] Refactoring of LWLock tranches
Дата
Msg-id 20151212181702.GH17938@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [PATCH] Refactoring of LWLock tranches  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [PATCH] Refactoring of LWLock tranches  (Robert Haas <robertmhaas@gmail.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Corey Huinker
Дата:
Сообщение: Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: WIP: Rework access method interface