Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock
От | Alexander Korotkov |
---|---|
Тема | Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock |
Дата | |
Msg-id | CAPpHfdtpVKQ8TQ78tnW84177jH_uh_+=Gva_HBw=0Kj+f=O3ng@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock
|
Список | pgsql-hackers |
On Thu, Dec 13, 2018 at 10:46 PM Andres Freund <andres@anarazel.de> wrote: > 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. Good point, thank you! ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: