I wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
>> Just a suspicion ... when looking at the B-tree page reclamation algorithm, I
>> had a thought that the logic in _bt_page_recyclable() was obsolete as of the
>> introduction (in 8.3) of xid-free read-only transactions.  A transaction
>> without a persistent xid does not hold back RecentXmin, so how could waiting
>> for a RecentXmin window to pass prove that no scan still holds a link to the
>> page?  Similarly, running VACUUMs do not hold back RecentXmin.

> Uh, sure they do.  It's their advertised snapshot xmin that counts, not
> their own xid (if any).

No, wait a second, I think you're right.  The existing mechanism should
protect against transactions that might be updating the btree, so the
worst possible consequences can't happen; but it seems possible that a
read-only transaction in flight to the page could get confused and give
wrong answers.  That would only explain transient failures not persistent
ones, though.

			regards, tom lane

In response to

• Re: strange nbtree corruption report at 2011-11-22 03:43:23 from Tom Lane

pgsql-hackers by date

Next:	From: Jeff Janes	Date: 2011-11-22 04:20:18
	Subject: Re: explain analyze query execution time
Previous:	From: Tom Lane	Date: 2011-11-22 04:14:33
	Subject: Re: strange nbtree corruption report