Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock
Date
Msg-id CAH2-WznZ7uDWwap_y9iHJO3LfD3efHRkUy+m2myRHSSoF7q3iw@mail.gmail.com
Whole thread Raw
In response to Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock  (Peter Geoghegan <pg@bowt.ie>)
Responses Re:Re: Connections hang indefinitely while taking a gin index'sLWLock buffer_content lock  (chenhj <chjischj@163.com>)
Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.

-- 
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Skylake-S warning
Next
From: Tom Lane
Date:
Subject: Re: Uninterruptible long planning of a query with too many WHERE clauses