Re: BUG #1800: "unexpected chunk number" during pg_dump
От | Alvaro Herrera |
---|---|
Тема | Re: BUG #1800: "unexpected chunk number" during pg_dump |
Дата | |
Msg-id | 20050811165238.GC20172@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: BUG #1800: "unexpected chunk number" during pg_dump ("Aaron Harsh" <ajh@rentrak.com>) |
Список | pgsql-bugs |
On Wed, Aug 10, 2005 at 06:07:24PM -0700, Aaron Harsh wrote: > > >>> Alvaro Herrera <alvherre@alvh.no-ip.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"
В списке pgsql-bugs по дате отправления: