Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 832202E023F for ; Tue, 18 Mar 2008 12:35:31 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 63329-06 for ; Tue, 18 Mar 2008 12:35:29 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id A80412E0222 for ; Tue, 18 Mar 2008 12:35:28 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m2IFZQ2M025828; Tue, 18 Mar 2008 11:35:26 -0400 (EDT) To: "Chadwick Horn" cc: pgsql-sql@postgresql.org Subject: Re: postgres server crashes unexpectedly In-reply-to: <785A9529D52A4C9891401C6DD0A22F24@ToshibaLaptop> References: <71EB10BF787341C28A47F33667D0D8FC@ToshibaLaptop> <7206.1205807551@sss.pgh.pa.us> <785A9529D52A4C9891401C6DD0A22F24@ToshibaLaptop> Comments: In-reply-to "Chadwick Horn" message dated "Tue, 18 Mar 2008 08:17:12 -0700" Date: Tue, 18 Mar 2008 11:35:26 -0400 Message-ID: <25824.1205854526@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/98 X-Sequence-Number: 30426 "Chadwick Horn" writes: > I keep getting this error: > Attempting reset: WARNING: terminating connection because of crash of another server process It looks to me like psql is managing to start a new connection before the postmaster notices the crash of the prior backend and tells everybody to get out of town. Which is odd, but maybe not too implausible if your kernel is set up to favor interactive processes over background --- it'd likely think psql is interactive and the postmaster isn't. > What could be doing this? It just started out of the blue... I reindexed the > index it mentioned and it seems to error out more... If you reindexed only the last-mentioned index, then you reindexed the wrong thing; it presumably died on the next index of story_member. I'd reindex the whole table rather than guess which that is. You should also consider the not-zero probability that you have more than one corrupted index. Keep reindexing tables until you can get through a database-wide VACUUM. regards, tom lane