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

Re: BUG #4929: Corrupted pg_class, possibly truncate/rollback related

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: "Robert Treat" <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4929: Corrupted pg_class, possibly truncate/rollback related
Date: 2009-07-21 01:48:29
Message-ID: 2196.1248140909@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> However I'm wondering if another 8.3.4 fix, the RecentGlobalXmin one,
> could be relevant here?
> http://archives.postgresql.org/pgsql-committers/2008-09/msg00105.php
> (I'm not seeing how it would be, but... note that the xids have got
> to the point that they'd appear to be in the past from the point of
> view of FirstNormalTransactionId)

Hmmm ... I think you're onto something.  My original speculation at
http://archives.postgresql.org/message-id/29544.1221061979@sss.pgh.pa.us
included a worry that the HOT patch could try to use RecentGlobalXmin
before it had gotten set.  In particular, before the patch you mention
above, the InitPostgres transaction would be running around and doing
quite a lot of system catalog access with an unset RecentGlobalXmin.
If it happened to try to execute heap_page_prune on a pg_class page,
there would be a risk of deciding that some valid tuple wasn't valid.
I don't have time to try to trace through the logic and see if this
explains Robert's problem, though.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-07-21 02:05:25
Subject: Re: Bug 4906 -- Left join of subselect incorrect
Previous:From: Andrew GierthDate: 2009-07-21 00:59:53
Subject: Re: BUG #4929: Corrupted pg_class, possibly truncate/rollback related

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