Subject: Re: transactions & concurrency

From: Gerry Stringer <[email-masked]>
Date: Fri, 22 May 92 03:51:59 -0700

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   ([email-masked])

---

From: postarch (Postgres Mailing Archive)
Date: Tue, 26 May 92 08:53:03 PDT

> 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
[email-masked]