Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA05812; Wed, 20 Nov 91 14:58:04 -0800
Message-Id: <9111202258.AA05812@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: Postgres is still not working...
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of "Wed, 20 Nov 91 17:13:24 EST."
             <9111202213.AA04311@postgres.Berkeley.EDU> 
Date: Wed, 20 Nov 91 14:53:03 PST

In message <9111202213.AA04311@postgres.Berkeley.EDU> you write:
> 
> Before a few days ago we were using Postgres very lightly, and only
> one person at a time.  Now a bunch of students are using it, and the
> problems have started since that time.  For the time being, we have
> maybe 3-5 people each using their own mini database at the same time.
> The number of users could grow though (but it won't if it keeps
> crashing like it does now...).

When a backend crashes the postmaster detects the condition and signals
all other currently running backends to die gracefully.  This is done
because it's possible that one of the backends that crashed could have
corrupted shared buffers and you don't want any of that to make it to
the disk.  From the problems you describe it sounds like this is what
might be happening.  Has anyone received an error message that tries
to explain _why_ it is dying? Something like:

  "I have been signalled by the postmaster."
  "Some backend process has died unexpectedly and possibly"
  "corrupted shared memory.  The current transaction was"
  "aborted, and I am going to exit.  Please resend the"
  "last query. -- The postgres backend"

If not then there is something wrong with the clean up utlities at your
installation.

> It seems that we have a problem with multiuser access to Postgres.  I
> thought that version 3 had fixed these problems...  If anyone can help
> me with this problem, I would appreciate it as I'm stuck...

version 3 fixed many of the multi-user problems. It did not apparently
fix all of them.  Its a little difficult to simulate all situations that
could arise in a multi-user installation.


Jeff Meredith
mer@postgres.berkeley.edu