Re: Row data corruption under 7.3.5

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

In response to

Browse pgsql-admin by date

  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