index 30df2447033e19cb9e2dc690dadda48a6a889d72..40ad0956e0048406aac5bb3c72a873e214849fe5 100644 (file)
opaque->btpo_next < scanblkno)
backtrack_to = opaque->btpo_next;
- /*
- * When each VACUUM begins, it determines an OldestXmin cutoff value.
- * Tuples before the cutoff are removed by VACUUM. Scan over all
- * items to see which ones need to be deleted according to cutoff
- * point using callback.
- */
ndeletable = 0;
nupdatable = 0;
minoff = P_FIRSTDATAKEY(opaque);
nhtidslive = 0;
if (callback)
{
+ /* btbulkdelete callback tells us what to delete (or update) */
for (offnum = minoff;
offnum <= maxoff;
offnum = OffsetNumberNext(offnum))
itup = (IndexTuple) PageGetItem(page,
PageGetItemId(page, offnum));
- /*
- * Hot Standby assumes that it's okay that XLOG_BTREE_VACUUM
- * records do not produce their own conflicts. This is safe
- * as long as the callback function only considers whether the
- * index tuple refers to pre-cutoff heap tuples that were
- * certainly already pruned away during VACUUM's initial heap
- * scan by the time we get here. (heapam's XLOG_HEAP2_PRUNE
- * records produce conflicts using a latestRemovedXid value
- * for the pointed-to heap tuples, so there is no need to
- * produce our own conflict now.)
- *
- * Backends with snapshots acquired after a VACUUM starts but
- * before it finishes could have visibility cutoff with a
- * later xid than VACUUM's OldestXmin cutoff. These backends
- * might happen to opportunistically mark some index tuples
- * LP_DEAD before we reach them, even though they may be after
- * our cutoff. We don't try to kill these "extra" index
- * tuples in _bt_delitems_vacuum(). This keep things simple,
- * and allows us to always avoid generating our own conflicts.
- */
Assert(!BTreeTupleIsPivot(itup));
if (!BTreeTupleIsPosting(itup))
{