> 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.
>
> That helps explain why 1 becomes the min for that brin tuple.
>
> Attached hack fixes the symptom but perhaps not the correct fix for this.
Why can't we fix summarize_range() in brin.c:
IndexBuildHeapRangeScan(heapRel, state->bs_irel, indexInfo, false, true,
heapBlk,
state->bs_pagesPerRange,
brinbuildCallback,
(void *) state);
This currently thoughtlessly passes scannumblocks as
state->bs_pagesPerRange. Shouldn't we change this so that
(scanStartBlock + scanNumBlocks) does not exceed scan->rs_nblocks?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
