Karsten Desler <[EMAIL PROTECTED]> writes:
> I don't know much about the postgres architecture and I don't know if bounds
> checking on-disk values on a read makes a lot of sense since usually one
> should be able to assume that there are no randomly flipped bits; but it
> would've been nice to have a sensible log entry as to what really
> happened.
FWIW, there is code in CVS HEAD that detects simple cases of corrupt
compressed data, though it's anyone's guess if it would've caught your
example here.
> Anyway, for future reference: Assuming that this is the only corruption,
> can I just UPDATE (or DELETE and reINSERT) the offending entry (maybe with a
> following REINDEX/VACUUM?) or do I need to restore a backup?
If only the one row is clobbered, you should be able to just delete and
re-insert it, assuming you can identify it in a way that doesn't crash
in itself (ctid is probably about the safest). Not sure if an UPDATE
would be safe.
My suspicion though is that you'll find that a large portion of that
page is damaged; that's usually what we've seen in such cases in the
past.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
