From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: BRIN INDEX value |
Date: | 2015-09-04 03:01:37 |
Message-ID: | 20150904030137.GJ2912@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-09-04 03:04:11 | Re: Fwd: Core dump with nested CREATE TEMP TABLE |
Previous Message | Alvaro Herrera | 2015-09-04 02:56:52 | Re: Freeze avoidance of very large table. |