Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA18310; Tue, 18 Feb 92 12:15:40 -0800
Message-Id: <9202182015.AA18310@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: no response from backend, exiting...
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Reply-To: mer@postgres.berkeley.edu
In-Reply-To: Your message of "Tue, 18 Feb 92 08:27:44 PST."
             <9202181627.AA13807@postgres.Berkeley.EDU>
Date: Tue, 18 Feb 92 12:15:31 PST

you write:

> nonetheless, if i am also running the monitor while i execute
> my program, and then i submit any query using the monitor, it
> still crashes, issuing the same message as before ("I have been
> signalled by the postmaster. Some backend process has died
> unexpectedly and ...).
> when i run the monitor again, it works ok.

It sounds like the backend is crashing.  The message you get means
exactly what it says.  That is, a backend had a non-zero exit status
and the postmaster assumes that it has to torch shared memory and
recreate it.  When it does this all other existing backends must be
restarted.  So the postmaster sends a previously arranged signal to
all existing backend processes (including the one that your terminal
monitor is talking to) which causes them to exit right away sending the
"I have been signalled..." message to the user.

> btw, what are all those temp_* files created in the data/base/mydb
> directory? can i delete them? (i have not touched them this time)

The temp_ files are temporary relations created while processing retrieve
into and some other queries.  When the query completes successfully the
file is removed.  If the backend were to crash before this happend the
temp_ stays there until the dba goes in and removes it via 'rm -f'

> and for my old database, when i run the backend standalone,
> following your advise, and i type any query, it dies with a
> 	Bus error (core dumped)
> message. do you think there is any way to recover this db?

If you can't run *any* queries (for example copy) then there isn't a way
to recover it.


Jeff Meredith
mer@postgres.berkeley.edu