Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA13941; Tue, 27 Apr 93 05:15:47 -0700
Date: Tue, 27 Apr 93 05:15:47 -0700
Message-Id: <9304271215.AA13941@postgres.Berkeley.EDU>
From: Gerry Stringer <gerry@camscan.co.uk>
Subject: Re deadlock ( bug in begin/end? replace?)
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu



I've been watching the mail over the last couple of days but still
haven't seen a definitive answer to avoiding deadlock. If:

>a replace query of the form:  
> 
>       replace foo (attribute1 =foo.attribute1 + 1) 
> 
>will first do a scan over foo (acquiring a readlock) then attempt to 
>write a new instance/row/tuple (acquiring a write lock).  any time you 
>"upgrade" a read lock to a write lock you're vulnerable to deadlock.

then how do I code a transaction that is guaranteed not to deadlock?
Would a dummy append do it or should I be considering my own locking
outside Postgres?

	thanks,
		gerry


+--------------------------------+---------------------------------+
|Gerry Stringer                  |Phone: +44 954 780926            |
|Cambridge Scanning Company Ltd  |Fax:   +44 954 789829            |
|Saxon Way                       |UUCP : gerry@camscan.co.uk       |
|Bar Hill                        |       gerry@camscan.uucp        |
|Cambridge CB3 8SL               |       			   |
|United Kingdom                  |                                 |
+--------------------------------+---------------------------------+