Re: BUG #4383: operations in a certain row makes server process terminate with signal 11

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marco Aurelio C(dot) Miranda" <macmiranda(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4383: operations in a certain row makes server process terminate with signal 11
Date: 2008-08-28 14:41:54
Message-ID: 10006.1219934514@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Marco Aurelio C. Miranda" <macmiranda(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Marco Aurelio Miranda 2008-08-29 01:05:19 Re: BUG #4383: operations in a certain row makes server process terminate with signal 11
Previous Message Craig Ringer 2008-08-28 11:18:09 Re: BUG #4384: jdbc driver not working