The following bug has been logged online:

Bug reference: 1800
Logged by: Aaron Harsh
Email address: ajh (AT) rentrak (DOT) com
PostgreSQL version: 7.4.6
Operating system: RedHat ES release 3, x86_64
Description: "unexpected chunk number" during pg_dump
Details:

Our regular pg_dump aborted this afternoon with this output:

pg_dump: ERROR: unexpected chunk number 0 (expected 1) for toast value
4294879152
pg_dump: SQL command to dump the contents of table "dataset_cache" failed:
PQendcopy() failed.
pg_dump: Error message from server: ERROR: unexpected chunk number 0
(expected 1) for toast value 4294879152
pg_dump: The command was: COPY public.dataset_cache (checksum, version_no,
bind_params, sql_statement, serialized_value, date_created) TO stdout;
pg_dump: *** aborted because of error

We saw the same message when we tried to cluster the effective table. The
problem went away after truncating the table.

I've searched the pgsql-bugs archives and found reports of this problem, but
haven't seen a solution. Is there a solution to keep this from happening in
the future? (Version upgrade maybe?)

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Mon, Aug 01, 2005 at 06:02:30AM +0100, Aaron Harsh wrote:

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.

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"La naturaleza, tan frágil, tan expuesta a la muerte... y tan viva"

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Alvaro Herrera wrote:

x86-64 systems will still boot and run 32-bit code fine (although
obviously memtest86 isn't going to test memory it can't address in
32-bit mode)

-O

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

The server is running off of ECC RAM on a RAID-10 set, so a one-off disk/RA=
M failure seems unlikely. The server had been running beautifully for 6 mo=
nths 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).


--=20
Aaron Harsh
ajh (AT) rentrak (DOT) com
503-284-7581 x347


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Wed, Aug 10, 2005 at 06:07:24PM -0700, Aaron Harsh wrote:
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"

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Unfortunately, the table doesn't show any problems now (I truncated it afte=
r the pg_dump failed)and so there's not a lot of further detail I can give =
you. I suppose this means that we'll have to wait until such time as the p=
roblem shows up again before we can continue.

Thanks for your help.

--=20
Aaron Harsh
ajh (AT) rentrak (DOT) com
503-284-7581 x347


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings