@ -239,8 +239,8 @@ initscan(HeapScanDesc scan, ScanKey key, bool keep_startblock)
* behaviors , independently of the size of the table ; also there is a GUC
* variable that can disable synchronized scanning . )
*
* Note that heap _parallelscan_initialize has a very similar test ; if you
* change this , consider changing that one , too .
* Note that table_block _parallelscan_initialize has a very similar test ;
* if you change this , consider changing that one , too .
*/
if ( ! RelationUsesLocalBuffers ( scan - > rs_base . rs_rd ) & &
scan - > rs_nblocks > NBuffers / 4 )
@ -1396,15 +1396,6 @@ heap_getnextslot(TableScanDesc sscan, ScanDirection direction, TupleTableSlot *s
* If the tuple is found but fails the time qual check , then false is returned
* but tuple - > t_data is left pointing to the tuple .
*
* keep_buf determines what is done with the buffer in the false - result cases .
* When the caller specifies keep_buf = true , we retain the pin on the buffer
* and return it in * userbuf ( so the caller must eventually unpin it ) ; when
* keep_buf = false , the pin is released and * userbuf is set to InvalidBuffer .
*
* stats_relation is the relation to charge the heap_fetch operation against
* for statistical purposes . ( This could be the heap rel itself , an
* associated index , or NULL to not count the fetch at all . )
*
* heap_fetch does not follow HOT chains : only the exact TID requested will
* be fetched .
*
@ -7085,7 +7076,7 @@ heap_compute_xid_horizon_for_tuples(Relation rel,
* Conjecture : if hitemid is dead then it had xids before the xids
* marked on LP_NORMAL items . So we just ignore this item and move
* onto the next , for the purposes of calculating
* latestRemovedxids .
* latestRemovedXid .
*/
}
else