Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA08918; Fri, 22 May 92 03:51:59 -0700
Date: Fri, 22 May 92 03:51:59 -0700
Message-Id: <9205221051.AA08918@postgres.Berkeley.EDU>
From: Gerry Stringer <gerry@camscan.co.uk>
Subject: Re: transactions & concurrency
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu


Thanks for your last reply, it certainly helps my understanding. 

A little further:

>> 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?

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


	Many thanks,

		gerry   (gerry@camscan.co.uk)