Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA00044; Tue, 12 May 92 09:29:11 -0700
Message-Id: <9205121629.AA00044@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: vacuum
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Reply-To: mer@postgres.berkeley.edu
In-Reply-To: Your message of "Wed, 06 May 92 05:15:06 PDT."
             <9205061002.AA03662@dpi.inpe.br> 
Date: Tue, 12 May 92 09:27:28 PDT

you write:

>I have a database where indexes and rules are defined along with nearly 40 relations. This database is used by sometime more than 8 users through copies of the same application running in different Sun's. At the beginning of the database's life everything seems to run OK, but some relatively long time latter the backend begins not to respond for some of the frontend processes. To solve this problem I use to vacuum the database and call ipcclean to clean up shared memories. I don't know if this is the best action to take, so I would be grateful for any suggestions or advices about the issue.

When you say the backend isn't responding, what exactly is happening?
Are you able to connect on a second try?

There is a known problem that crops up only every once in a while.  When
you start a handful (more than 1) front-end process concurrently one or
more of them will not successfully connect to the backend.  I have been
able to sporatically reproduce this, but am not sure what the problem could
be.  I would like to blame it on os bugs, but it happens on both sparc and
decstations in the same manner...


Jeff Meredith
mer@postgres.berkeley.edu
