Re: BUG #4383: operations in a certain row makes server process terminate with signal 11
От | Tom Lane |
---|---|
Тема | Re: BUG #4383: operations in a certain row makes server process terminate with signal 11 |
Дата | |
Msg-id | 10006.1219934514@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #4383: operations in a certain row makes server process terminate with signal 11 ("Marco Aurelio C. Miranda" <macmiranda@gmail.com>) |
Ответы |
Re: BUG #4383: operations in a certain row makes server process terminate with signal 11
|
Список | pgsql-bugs |
"Marco Aurelio C. Miranda" <macmiranda@gmail.com> writes: > 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
В списке pgsql-bugs по дате отправления: