Re: slow startup due to LWLockAssign() spinlock

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: slow startup due to LWLockAssign() spinlock
Дата
Msg-id 654.1398357793@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: slow startup due to LWLockAssign() spinlock  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: slow startup due to LWLockAssign() spinlock  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-04-24 11:02:44 -0400, Tom Lane wrote:
>> FWIW, I like the LWLockAssignBatch idea a lot better than the currently
>> proposed patch.  LWLockAssign is a low-level function that has no business
>> making risky assumptions about the context it's invoked in.

> I don't think LWLockAssignBatch() is that easy without introducing
> layering violations. It can't just return a pointer out of the main
> lwlock array that then can be ++ed clientside because MainLWLockArray's
> stride isn't sizeof(LWLock).

Meh.  I knew this business of using pointers instead of indexes would
have some downsides.

We could return the array stride ... kinda ugly, but since there's
probably only one consumer for this API, it's not *that* bad.  Could
wrap the stride-increment in a macro, perhaps.
        regards, tom lane



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

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: 9.4 Proposal: Initdb creates a single table
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 9.4 Proposal: Initdb creates a single table