Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock
От | Andres Freund |
---|---|
Тема | Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock |
Дата | |
Msg-id | 20181213194611.zttrlelwi7qu2ewc@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock (Alexander Korotkov <aekorotkov@gmail.com>) |
Ответы |
Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock
|
Список | pgsql-hackers |
Hi, On 2018-12-13 22:40:59 +0300, Alexander Korotkov wrote: > It doesn't mater, because we release all locks on every buffer at one > time. The unlock order can have effect on what waiter will acquire > the lock next after ginRedoDeletePage(). However, I don't see why one > unlock order is better than another. Thus, I just used the rule of > thumb to not change code when it's not necessary for bug fix. I think it's right to not change unlock order at the same time as a bugfix here. More generally I think it can often be useful to default to release locks in the inverse order they've been acquired - if there's any likelihood that somebody will acquire them in the same order, that ensures that such a party would only need to wait for a lock once, instead of being woken up for one lock, and then immediately having to wait for the next one. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: