Re: [PATCH] Refactoring of LWLock tranches

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [PATCH] Refactoring of LWLock tranches
Дата
Msg-id CAA4eK1LUvWUvSbsn+q5MJYASjqFu4YXnxNBGOAHbVhhkUm-QFA@mail.gmail.com
обсуждение исходный текст
Ответ на 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 Fri, Feb 5, 2016 at 3:17 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
>
> I think we ought to move the buffer mapping, lock manager, and
> predicate lock manager locks into their own tranches also, perhaps
> using this new named-tranche facility.
>

Makes sense and attached patch implements it using new named
tranches facility.  One thing to note is that to make it work on
EXEC_BACKEND builds, I have passed the individual LWLock
array via save-restore backendparams mechanism.  Now instead
we could have initialised the LWLock arrays in each backend at
start-up and I have tried to analyse that way as well, but we need
to use NamedLWLockTrancheArray instead of
NamedLWLockTrancheRequestArray in GetNamedLWLockTranche()
and not only that, we also need to store number of locks
information in NamedLWLockTrancheArray as well.  So it seems
it is better to use save-restore backendparams mechanism for
passing LWLock arrays.


>  In addition, I think we should
> get rid of NumLWLocks().  It's no longer calculating anything; it just
> returns NUM_FIXED_LWLOCKS, and with the changes described in the first
> sentence of this paragraph, it will simply return
> NUM_INDIVIDUAL_LWLOCKS.  We don't need a function just to do that; the
> assignment it does can be moved to the relevant caller.
>

Agreed and we don't even need an array of LWLockCounter's, just one
counter is sufficient for tranches.  Apart from this function
LWLockAssign() seems redundant to me after new implementation
of named tranches, so I have removed that as well.



With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Support for N synchronous standby servers - take 2