DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:from:to:cc:references:in-reply-to:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole;
	b=tD5AsAlrFvvjTYFQbEgC6WWv4WdoAqy64ZPvv0iuQh9WCCuaphF16zdwNTSX5mrfRO+tn58YVFqwQ00oj90wMe53UZkxVWorWDlKije29ACUy9GW/4p9KmgHTCepp7pPsO8CrpbjaVSXJjUSAJYwFl5WAPMTUaivsdojq7fWERk=
Message-ID: <8ECADC453D394D089097C660876A9BA7@ToshibaLaptop>
From: "Chadwick Horn" <chadhorn@gmail.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-sql@postgresql.org>
References: <71EB10BF787341C28A47F33667D0D8FC@ToshibaLaptop>
	<7206.1205807551@sss.pgh.pa.us>
	<785A9529D52A4C9891401C6DD0A22F24@ToshibaLaptop>
	<25824.1205854526@sss.pgh.pa.us>
In-Reply-To: <25824.1205854526@sss.pgh.pa.us>
Subject: Re: postgres server crashes unexpectedly 
Date: Tue, 18 Mar 2008 08:48:47 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

> "Chadwick Horn" <chadhorn@gmail.com> 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.

Is there a way to disable this or to make both interactive and/or 
background?

>
>> 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.

I have VACUUM'd it until it's fibers are coming out. It seems to crash at 
various places (which, most likely, would be resolved if question #1 above 
is possible) and holds no consistancy. The error logs provide even fewer 
clues than the verbose output.


-chadwick