| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: BRIN INDEX value |
| Date: | 2015-09-04 01:10:51 |
| Message-ID: | 55E8EF9B.4090900@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Thanks,
Amit
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2015-09-04 01:14:32 | Re: Fwd: Core dump with nested CREATE TEMP TABLE |
| Previous Message | Tom Lane | 2015-09-04 00:57:43 | Re: Fwd: Core dump with nested CREATE TEMP TABLE |