Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA26722; Thu, 21 May 92 07:24:25 -0700
Date: Thu, 21 May 92 07:24:25 -0700
Message-Id: <9205211424.AA26722@postgres.Berkeley.EDU>
From: Gerry Stringer <gerry@camscan.co.uk>
Subject: transactions & concurrency
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu



Hello, 
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). For example, I have a
transaction:

begin
retrieve (tasklist.oid,tasklist.all) where tasklist.processing="no" ;
<get the oid ...>
replace tasklist(processing="yes",host="$hostname",pid="$pid",
    started="now") where tasklist.oid="$oid"
end

I ran this code concurrently on 2 m/cs and eventually got
 
 NOTICE:May 21 13:20:22:Timeout -- possible deadlock
 WARN:May 21 13:20:22:WaitOnLock: error on wakeup - Aborting this transaction 

as an error from both processes. The deadlock appeared to occur on the
'retrieve' and the error message just after  Subsequently, both
'replace' operations continued but the result on the row concerned was
to leave some fields not updated.

In this situation:

   1. should the locking scheme block all but one transaction 
   2. should the fact that deadlock has occurred be reported back to
      the application 
   3. something else I haven't thought of

How should I code an application to cope with this?


	Many thanks,

		gerry  (gerry@camscan.co.uk)


NB. Postgres 3.0 (still), SUN IPC,SUNOS 4.1.1