I wrote:
> Noah Misch <noah@leadboat.com> writes:
>> We achieve that division of labor for XLOG_BTREE_DELETE by examining the old
>> contents before RestoreBkpBlocks(). This is safe, I think, because we only
>> examine the page when the system has running hot standby backends, and we only
>> allow hot standby connections when recovery has proceeded far enough to fix
>> all torn and ahead-of-EndRecPtr pages.
> Egad. That's seriously underdocumented as well.
And buggy, now that I look at it. Suppose a new backend starts
immediately after CountDBBackends runs? That's okay, because it can't
possibly have seen any page links that we would need to conflict for
... but because the code is lazy and returns InvalidTransactionId,
we'll throw a conflict on it anyway.
The case where the loop doesn't find any live tuples seems problematic
as well. There's a comment asserting that this will happen "very
rarely", which is neither comforting nor backed up by any evidence or
argument. ISTM that a page that VACUUM has removed tuples from might
very well have a preimage consisting only of dead tuples.
regards, tom lane