Re: GIN data corruption bug(s) in 9.6devel - Mailing list pgsql-hackers

From Noah Misch
Subject Re: GIN data corruption bug(s) in 9.6devel
Date
Msg-id 20160428061353.GA2179632@tornado.leadboat.com
Whole thread Raw
In response to Re: GIN data corruption bug(s) in 9.6devel  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers
On Tue, Apr 26, 2016 at 08:22:03PM +0300, Teodor Sigaev wrote:
> >>Check my reasoning: In version 4 I added a remebering of tail of pending
> >>list into blknoFinish variable. And when we read page which was a tail on
> >>cleanup start then we sets cleanupFinish variable and after cleaning that
> >>page we will stop further cleanup. Any insert caused during cleanup will be
> >>placed after blknoFinish (corner case: in that page), so, vacuum should not
> >>miss tuples marked as deleted.
> >
> >Yes, I agree with the correctness of v4.  But I do wonder if we should
> >use that early stopping for vacuum and gin_clean_pending_list, rather
> Interesting, I've missed this possible option
> 
> >than just using it for user backends.  While I think correctness
> >allows it to stop early, since these routines are explicitly about
> >cleaning things up it seems like they should volunteer to clean the
> >whole thing.
> 
> I believe that autovacuum should not require guaranteed full clean up, only
> vacuum and gin_clean_pending_list() should do that. In all other cases it
> should stop early to prevent possible infinite cleanup. Patch attached.

Teodor, this item remains open after twenty-three days of you owning it.  At
this pace, 9.6beta1 will have an unreliable GIN implementation.  What things
must happen so you can close this item, and when will you do those things?



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co
Next
From: Christian Ullrich
Date:
Subject: Re: Parallel build with MSVC