"Marc Mitchell" <marcm@eisolution.com> writes:
> In each case, by examining the copy table output up to the point where
> it errors out, a single row could be identified that contained corrupted
> char/varchar values but could be queried using primary key or numeric
> lookups. We've been able to work around the issue by deleting the row
> and manually re-inserting it based on values determined from a previous
> backup. Note that in each case, it has been determined that the corrupt
> row existed without a problem earlier as it could be found in old
> backups. Thus the rows seem to get into the table ok but got wacked at
> some future point in time.
> Any ideas on what's causing this?
Hardware problems possibly? You might try running memtest86 or some
such.
It would be good to take note of the exact bit pattern of the
corruption, if you can match up correct and corrupted versions of the
rows.
regards, tom lane