Return-Path: mao
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA22087; Wed, 24 Jul 91 18:45:54 -0700
Message-Id: <9107250145.AA22087@postgres.Berkeley.EDU>
From: mao@postgres.Berkeley.EDU (Mike Olson)
Subject: Re: postgres system problems
To: postgres@postgres.berkeley.edu
In-Reply-To: Your message of "Thu, 25 Jul 91 11:10:20 +0900."
             <9107250111.AA21722@postgres.Berkeley.EDU> 
Date: Wed, 24 Jul 91 18:44:43 PDT

> With the well known multiuser problems in postgres 2.1 occurring all the time
> here we need some way of making the system vaguely reliable.

in a couple of weeks, 3.0 will be released, and will fix these problems.
(i know this doesn't help you immediately, but all the big database companies
say this).

> Is using postgres
> directly the only alternative (to monitor)? If so what is the easiest way
> to allow multiple users to access there own (different) databases with
> postgres? Currently I get an error message from postgres complaining that
> the user-id doesn't match the db owner id (postgres). If I chown all the
> database files I still get the same error message.

postgres (the binary of that name) needs to be setuid postgres (the user
of that name) to work correctly.  user postgres should have uid 6.

running individual versions of postgres is tricky, since postgres will still
allocate semaphores for locking.  every backend will allocate its own if it's
not started by the postmaster, so you'll run out of semaphores pretty quickly
and you'll also modify shared data structures at the same time.  this is Bad
News.

the only way around these problems is

    +  make sure your system has lots of semaphores, so that several
       postgres backends can be run interactively at the same time.

    +  give every user not just his own database, but his own POSTGRESHOME,
       with a separate data/ directory.  the reason for this is to keep
       different users' backends from updating one another's pg_variable,
       pg_log, and pg_time relations, which are shared by all databases
       under a given POSTGRESHOME.

best advice is to wait for 3.0 to come out, if you can manage it.

incidentally, 3.0 will (once again) change the system metadata and layout
of user data in relations.  this means that, once again, your existing
databases will not be usable with the new release.  we encourage you to
plan ahead if you want your data to persist -- use the copy command to get
your relations to unix files, so you can copy them back into the new version
when it's released.
					mike olson
					postgres research group
					uc berkeley
					mao@postgres.berkeley.edu