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
|
Список | 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 по дате отправления: