Resent-From: postman (POSTGRES mailing list)
Resent-Message-Id: <9311011616.AA09196@postgres.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
Message-Id: <199311011616.IAA05711@faerie.CS.Berkeley.EDU>
From: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
To: jh@efd.lth.se (Joergen Haegg)
Cc: postgres@postgres.Berkeley.EDU
Subject: Re: begin/end, where do I find more info about them? 
In-Reply-To: Your message of 1 Nov 1993 12:06:40 GMT 
	     <2b2u4g$3vr@nic.lth.se> 
Date: Mon, 01 Nov 93 08:16:27 -0800
Resent-To: postgres-dist
Resent-Date: Mon, 01 Nov 93 08:16:32 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