From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Marc Mitchell" <marcm(at)eisolution(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Row data corruption under 7.3.5 |
Date: | 2004-03-17 16:53:36 |
Message-ID: | 25825.1079542416@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
"Marc Mitchell" <marcm(at)eisolution(dot)com> writes:
> This is follow-up to a problem first reported on 3/1/04. The problem
> has continued to occur intermittently and recently we experienced the
> first occurrence where the first column of a table was the column where
> the corrupted and thus we could not recover it.
It would be useful to look at pg_filedump output for the affected pages.
See http://sources.redhat.com/rhdb/utilities.html to get that program.
I find "-i -f" options to be its most useful display format, although
the raw hex dump (-d) is also good to look at when investigating
data corruption. The first part of the TID (15 in your latest example)
is the block number within the table file; you can use contrib/oid2name
if you need help figuring out which file is the table you want.
> We've observed nothing that would lead us to believe there are any
> hardware problems.
Have you done anything to proactively test for hardware problems?
memtest86, badblocks, etc? It's possible you have a software problem,
but the symptoms sound more like hardware glitches to me.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jack Kerkhof | 2004-03-17 19:29:56 | pgdump - What happens to data modifications (INSERT, UPDATE, DELETE) while pgdump is running? |
Previous Message | scott.marlowe | 2004-03-17 16:51:20 | Re: Row data corruption under 7.3.5 |