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 | CAPpHfduixeHRS-zH4G3i3jPdJ6WAjcdxRpiAK+AGKC2h+UWXYA@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 Tue, Dec 4, 2018 at 8:01 PM Andres Freund <andres@anarazel.de> wrote: > On 2018-11-10 17:42:16 -0800, Peter Geoghegan wrote: > > On Wed, Nov 7, 2018 at 5:46 PM Peter Geoghegan <pg@bowt.ie> wrote: > > > Teodor: Do you think that the issue is fixable? It looks like there > > > are serious issues with the design of 218f51584d5 to me. I don't think > > > the general "there can't be any inserters at this subtree" thing works > > > given that we have to couple buffer locks when moving right for other > > > reasons. We call ginStepRight() within ginFinishSplit(), for reasons > > > that date back to bug fix commit ac4ab97e from 2013 -- that detail is > > > probably important, because it seems to be what breaks the subtree > > > design (we don't delete in two phases or anything in GIN). > > > > Ping? > > > > This is a thorny problem, and I'd like to get your input soon. I > > suspect that reverting 218f51584d5 may be the ultimate outcome, even > > though it's a v10 feature. > > Teodor, any chance for a response here? It's not OK to commit something > and then just not respond to bug-reports, especially when they're well > diagnose and clearly point towards issues in a commit of yours. Unfortunately, Teodor is unreachable at least till next week. > Alexander, CCing you, perhaps you could point the thread out to Teodor? I'll take a look at this issue. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: