joseph speigle <joe.speigle@jklh.us> writes:
> no, but perhaps I will. but since there's only this one corrupted
> table, it was trying to add a third column "uname" which was where it
> went bad. It might have been this command alter table calling add
> uname character varying(30) not null default 'joe';
Seems unlikely. ALTER TABLE ADD COLUMN has been in Postgres since
forever; I think it's real unlikely that the sequence of operations
you showed would have misbehaved. If you'd done some weird sequence
of column adds and drops, I'd be more prepared to credit a bug (since
DROP COLUMN is new in 7.3) ... but even then, damage consisting of
isolated corruption of different kinds in a few different rows doesn't
sound like a very probable symptom. I suspect the damage was already
there and the UPDATE was just the first operation that happened to touch
the clobbered row.
I'd look for hardware explanations if I were you.
regards, tom lane