From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: BRIN INDEX value |
Date: | 2015-09-04 00:22:49 |
Message-ID: | 20150904.092249.717969537377115253.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> The summarization during VACUUM invokes IndexBuildHeapRangeScan() which is
> passed scanStartBlock and scanNumBlocks. If scanStartBlock + scanNumBlocks
>> heapTotalBlocks, further down the line, heapgettup() may start returning
> tuples from the beginning given the following code in it:
>
> page++;
> if (page >= scan->rs_nblocks)
> page = 0;
>
> finished = (page == scan->rs_startblock) ||
> (scan->rs_numblocks != InvalidBlockNumber ?
> --scan->rs_numblocks == 0 :
> false);
>
> Where finished indicates whether it thinks the end of heap is reached.
>
> 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.
I vaguely recall that more internal inspecting type brin regression
test was removed because it depends on contrib modules. I am not sure
whether the decision was appropreate or not.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-09-04 00:29:40 | Re: Fwd: Core dump with nested CREATE TEMP TABLE |
Previous Message | Josh Berkus | 2015-09-04 00:17:25 | Re: Freeze avoidance of very large table. |