I wrote: > Noah Misch <n...@leadboat.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers