Resent-From: postman (POSTGRES mailing list)
Resent-Message-Id: <9311011641.AA09484@postgres.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
To: postgres@postgres.Berkeley.EDU
Path: postgres.Berkeley.EDU!postman
From: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
Newsgroups: lth.lists.postgres
Subject: Re: begin/end, where do I find more info about them?
Date: 1 Nov 1993 17:41:11 +0100
Organization: Lund Institute of Technology, Sweden
Lines: 25
Message-Id: <199311011616.IAA05711@faerie.CS.Berkeley.EDU>
Resent-To: postgres-dist
Resent-Date: Mon, 01 Nov 93 08:41:36 PST

jh@efd.lth.se (Joergen Haegg) writes:
> It seems as if postgres locks the class completely for all
> except the process that made the first append or replace.
> It is locked for all other processes until the first process
> executes 'end'.
> 
> Should it not be possible to read all instances, but not to change
> any instance that has changed but not committed?
> 
> Can anyone explain this?

sure -- "table-level locking on base classes."

what you're describing is tuple-level locking.  some commercial
vendors still don't provide this -- it's hard to do correctly 
and efficiently.  there's no research mileage in providing
it so it's unlikely [i don't make policy so i won't say anything
stronger] that you'll see it in postgres any time soon.

i should note that postgres contains code that implements a 
simple escalating multilevel lock manager, and there's a note
indicating that it dies in overhead..
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki