Re: BUG #1800: "unexpected chunk number" during pg_dump

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Aaron Harsh <ajh(at)rentrak(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1800: "unexpected chunk number" during pg_dump
Date: 2005-08-11 16:52:38
Message-ID: 20050811165238.GC20172@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Aug 10, 2005 at 06:07:24PM -0700, Aaron Harsh wrote:
> > >>> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> 08/10/05 9:03 AM >>>
> > On Mon, Aug 01, 2005 at 06:02:30AM +0100, Aaron Harsh wrote:
> > > pg_dump: ERROR: unexpected chunk number 0 (expected 1) for toast value
> > > ...
> > Looks very much like the table was corrupted. Maybe you should try to
> > test your RAM and disks. Not sure how to do that on x86-64 though,
> > unless the test utility at www.memtest86.com has been ported to it.
>
> The server is running off of ECC RAM on a RAID-10 set, so a one-off
> disk/RAM failure seems unlikely. The server had been running
> beautifully for 6 months prior to this error, and hasn't been
> evidencing the problem since, so it seems unlikely that this is due to
> a bad DIMM or RAID controller.
>
> The timing might be a coincidence, but this error happened within a
> day of our OID counter wrapping around back to 0. (Although Tom Lane
> mentioned in pgsql-general that he was inclined to consider the timing
> a coincidence).

Not sure what else to attribute the failure to then. But I should point
out that Oid normally wraps to FirstNormalObjectId (known as
BootstrapObjectIdData on previous sources), which is 16384, not 0.

Anyway I was originally thinking the problem data was 4294879152
(0xFFFEA7B0), not the 0. Have you tried to manually extract the data
from the dataset_cache table? You could try figuring out what page
contains the bad data, and manually peek into it using pg_filedump.

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"Uno puede defenderse de los ataques; contra los elogios se esta indefenso"

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Marc G. Fournier 2005-08-11 16:54:46 Re: [8.0.0] out of memory on large UPDATE
Previous Message Richard Huxton 2005-08-11 14:47:47 Re: BUG #1819: COPY filename rejects Windows format path