Re: BRIN INDEX value - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: BRIN INDEX value
Date
Msg-id 20150904030137.GJ2912@alvherre.pgsql
Whole thread Raw
In response to Re: BRIN INDEX value  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: BRIN INDEX value  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
Amit Langote wrote:
> On 9/4/2015 9:22 AM, Tatsuo Ishii wrote:
> >>
> >> In this case, scan->rs_startblock is 384 set by IndexBuildHeapRangeScan()
> >> using heap_setscanlimits(). One can imagine how the above heap finish
> >> criteria might not work as expected.
> > 
> > What scares me is:
> > 
> > 1) the bug will not be found unless someone inspects the internal data
> >    of BRIN. Regression test is useless here.
> > 
> > 2) the bug effectively causes vacuum scans the heap *twice*, which
> >    will produce lots of I/O if the heap is not small.
> > 
> > 3) I wonder if other index type is suffered by this type of bug.
> > 
> 
> About 3, it seems unlikely. Both the IndexBuildHeapRangeScan() and
> heap_setscanlimits() were introduced by the BRIN patch and I didn't find
> anything else using it, yet.

As I recall, there's some patch that Robert Haas or Amit Kapila that
wants to use that function.  Maybe something in the parallel seqscan
patch series?

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Tom Lane
Date:
Subject: Re: Fwd: Core dump with nested CREATE TEMP TABLE