From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tom Duffey <tduffey(at)techbydesign(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: could not access status of transaction |
Date: | 2009-03-26 02:02:21 |
Message-ID: | 11462.1238032941@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Duffey <tduffey(at)techbydesign(dot)com> writes:
> One of our databases suffered a problem yesterday during a normal
> update, something we have been doing for years. Near the end of the
> process a foreign key constraint is rebuilt on a table containing
> several hundred million rows. Rebuilding the constraint failed with
> the following message:
> ERROR: could not access status of transaction 4294918145
> DETAIL: Could not open file "pg_clog/0FFF": No such file or directory.
This looks like a garden-variety data corruption problem to me.
Trashed rows tend to yield this type of error because the "xmin"
transaction ID is the first field that the server can check with
any amount of finesse. 4294918145 is FFFF4001 in hex, saith my
calculator, so it looks like a bunch of bits went to ones --- or
perhaps more likely, the row offset in the page header got clobbered
and we're looking at some bytes that never were a transaction ID
at all.
So I'd try looking around for flaky RAM, failing disks, loose cables,
that sort of thing ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Uckun | 2009-03-26 02:20:38 | Re: log shipping from 64 bit linux server to a 32 bit linux server |
Previous Message | Scott Marlowe | 2009-03-26 01:57:36 | Re: log shipping from 64 bit linux server to a 32 bit linux server |