Skip site navigation (1) Skip section navigation (2)

Re: strange nbtree corruption report

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: strange nbtree corruption report
Date: 2011-11-22 04:17:40
Message-ID: 1811.1321935460@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group