Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA17077; Tue, 26 May 92 08:54:23 -0700
Message-Id: <9205261554.AA17077@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: transactions & concurrency
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Reply-To: mer@postgres.berkeley.edu
In-Reply-To: Your message of "Fri, 22 May 92 03:51:59 PDT."
             <9205221051.AA08918@postgres.Berkeley.EDU> 
Date: Tue, 26 May 92 08:53:03 PDT

you write:

> >> I could do with some clarification about how Postgres currently, and in
> >> the near future, copes with transactions attempting interleaved access
> >> to data (the classic potential deadlock). 
> >> 
> ...
> ...
> >> In this situation:
> >>    1. should the locking scheme block all but one transaction 
> 
> >	In utopia.  Under 2PL this depends on the timing.
> 
> 
> I think what I had in mind was the concept of an `exclusive read' type
> of lock which would cause one transaction to block (I used to work on
> the internals of a non-relational DB which allowed a read/write lock
> on the equivalent of a relation).
> 
> Does everybody simulate this by having a dummy relation/row to update
> at the start of a transaction?

This is a good question.  In postgres you have to do some sort of update
in order to gain exclusive access to the relation.  I don't know if this
would do what you want it to do on systems that implement finer grain
locking.  A dummy update might only lock the page or the tuple that the
update affected.

> Do you have any plans to give a programming interface to locking?

Not right now no.

Jeff Meredith
mer@postgres.berkeley.edu