Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group