Re: Block level concurrency during recovery

Simon Riggs  writes:
> VACUUM with a btree index proceeds like this:
> 1. Scan table
> 2. Remove rows from btree identified in (1)
> 3. Remove rows from heap identified in (1)

> The purpose of the additional locking requirements during (2) for btrees
> is to ensure that we do not fail to find the rows identified in (1),
> because the rows can move after (1) and during (2) because of block
> splits. 

No, you are missing the point.  One purpose of the additional locking
requirements is to ensure that there is not a concurrent process that
has read a btree index entry just before you removed it but arrives at
the heap page only after you removed the heap entry (and, perhaps,
replaced it with some other row that doesn't match the index entry at
all).  This is clearly still a risk in a hot-standby environment.
		regards, tom lane