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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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