> the behavior I'm about to demonstrate started to happen after a forced
> reboot but fsck hasn't found anything wrong with the ext3 filesystem.
fsck doesn't even think about whether the data inside user files is
any good.
> Look what happens when I select the id field of a particular row in this
> table:
>> select id from uab_message_read where id=249222;
> id
> ------------
> 1714385506
> (1 row)
If you're lucky, this is just a corrupted index on uab_message_read.id,
and can be fixed via REINDEX. Otherwise, what you've got is a corrupted
table.
> And when I try to select any other field of this row or to update any of the
> fields or to delete the row, the client outputs the following message:
> server closed the connection unexpectedly
That part sounds more like the table row is corrupted :-(. If you
aren't in a position to restore the whole table from backup, you'll
need to try to identify and wipe out the broken row. Usually zeroing
its whole page is the easiest way to do this, though you'll want to
see what else is on that page first. Check the PG archives for
discussions of recovering from corrupted-data scenarios.
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
No comments:
Post a Comment