> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
