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

Re: PG_DUMP error : unexpected chunk number

From: "mailtolouis2020-postgres(at)yahoo(dot)com" <mailtolouis2020-postgres(at)yahoo(dot)com>
To: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
Cc: Postgres <pgsql-general(at)postgresql(dot)org>
Subject: Re: PG_DUMP error : unexpected chunk number
Date: 2011-10-31 11:17:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general

Thanks for the info.

I've sorted out my problem by recreating the table and re-insert back the data exclude the corrupted row into the newly create table. And went back to my old backup to get back the data before it corrupt. I was lucky only 1 row affected.


>From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
>To: "mailtolouis2020-postgres(at)yahoo(dot)com" <mailtolouis2020-postgres(at)yahoo(dot)com>
>Cc: Postgres <pgsql-general(at)postgresql(dot)org>
>Sent: Saturday, October 29, 2011 5:05 PM
>Subject: Re: [GENERAL] PG_DUMP error :  unexpected chunk number
>On 10/28/2011 06:24 PM, mailtolouis2020-postgres(at)yahoo(dot)com wrote:
>> Hello,
>> I think I got a big problem now, I'm not able to do pg_dump on one of my
>> production database. When I do pg_dump it give me this error:
>> pg_dump: Error message from server: ERROR: unexpected chunk number
>> 18390760 (expected 4) for toast value 92784 in pg_toast_88487
>> I believe this message mean that my database is corrupted.
>Yup, pretty much. Check your hard drives. It's not impossible that there's a PostgreSQL bug that's caused the issue, but it's more likely going to be a hard drive, RAID array, or system memory/cpu/heat issue.
>For recovery: First, stop postgresql and take a file-level copy of your whole database. Keep that copy somewhere safe, in case your repair efforts make the issue worse.
>In this case, I'd probably try zeroing damaged pages as my first recovery effort. That's a bit of a big hammer, but might let you get a dump out. It WILL DESTROY DATA, so I'd recommend doing it by copying your backup to another directory and running a temporary postgresql instance with zero_damaged_pages enabled on it, then trying to dump from the temporary postmaster you've started. That way you don't have to mess with your original running database.
>It might help to look up which "real" table the pg_toast_88487 TOAST table is associated with, and see how important it is. Use pg_catalog for that; see the documentation.
>Craig Ringer
>-- Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
>To make changes to your subscription:

In response to

pgsql-general by date

Next:From: ddaiDate: 2011-10-31 11:49:12
Subject: salve.pgsql-general
Previous:From: Thomas StrunzDate: 2011-10-31 08:16:02
Subject: Installing an Extension

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