Delivery-Date: Fri, 17 Sep 93 11:20:27 PDT
Resent-From: postman (POSTGRES mailing list)
Resent-Message-Id: <9309171815.AA04250@postgres.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
Message-Id: <199309171816.LAA10078@faerie.CS.Berkeley.EDU>
From: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
To: neves@ils.nwu.edu
Cc: postgres@postgres.Berkeley.EDU
Reply-To: postgres@postgres.Berkeley.EDU
Subject: Re: more survey summary 
In-Reply-To: Your message of Fri, 17 Sep 93 10:28:06 CDT 
	     <9309171528.AA19224@aristotle.ils.nwu.edu> 
Date: Fri, 17 Sep 93 11:16:27 -0700
Resent-To: postgres-dist
Resent-Date: Fri, 17 Sep 93 11:15:51 PDT

in general, i would agree that multiuser reliability isn't very good.
there are some gotchas in protecting shared state [kristin wright
is looking at some of those] and the way fatal exceptions are handled
can make life really inconvenient (see below).

> - We get occasional deadlocks on replaces if the timing is bad.  I
> would assume though that if we had more than two people writing to the
> database the frequency of this would increase.

there was a discussion of this a few months ago.  the moral equivalent
of update locks (and SELECT... FOR UPDATE) would help but i don't think 
there are any current plans to add those.

> I tried using Postgres (on Sun sparcs) in a lab with 15 students each with
> their own database (which isn't quite what you want).

if you want to give people a taste of database use, why not use a real
SQL engine.  or, if you can't afford it, ingres89 (which doesn't do any
neat stuff but is smaller and more reliable and also runs on sparcs).

on the other hand, if people are *writing user extensions*, you want 
each of them under their own *postmaster* (meaning a separate PGDATA
and sufficient shared memory/semaphores for each).  why?  during the 
debugging phase, user-defined functions tend to cause the system to 
core (more so than usual :-).  when one backend cores, the postmaster 
takes down ALL of its other children (since the dead one may have 
corrupted shared state, i.e., the lock table and buffer pool).  even
ignoring other reliability issues, nobody can make *any* progress in 
this scenario.  (mike olson and jeff meredith tell some pretty good 
horror stories about trying to support the grad dbms class at UCB when 
people were trying to write ADTs and running under a single postmaster..)

you can use untrusted functions but only if the user-defined functions 
don't have to call into the backend server.

> In the end only 2 or 3
> students at any one time could use the system without the postmaster
> self destructing. I was impressed by the tenacity of the students.

hmm.  i haven't been able to actually crash [core] the postmaster 
since it was rewritten for 4.1 (not that it's hard to crash the 
backend).  the major failure mode for the postmaster happens when 
it tries to reinitialize shared state and one of the sysV ipc calls 
fails for some reason.  something else i never had a chance to look
into .. :-P

> I've had simular experiences to the others who responded.
> Any time I try to access a data base in parallel, eventually
> one of the backend processes will hang.  It will eat CPU and
> never terminate and all other backends just wait.

you know, i've never seen a 4.1 backend infinite-loop.  dump core, yes,
spin during deadlock, yes (though the deadlock period is relatively short),
but spin *forever*, never.  i'm sure someone here would be interested in 
knowing how to reproduce this.
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki