Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA28213; Wed, 21 Apr 93 16:14:53 -0700
Message-Id: <9304212314.AA28213@postgres.Berkeley.EDU>
From: Jeff Meredith <mer@miro.com>
Subject: Re: bug in begin/end? replace?
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of "Wed, 21 Apr 93 14:45:38 PDT."
             <9304212145.AA27242@postgres.Berkeley.EDU> 
Date: Wed, 21 Apr 93 16:11:45 -0700
From: Jeff Meredith <mer@miro.com>

message <9304212145.AA27242@postgres.Berkeley.EDU> read as follows:

> (1) nat was looking for a way not to have to deal with aborts on
> deadlock.  i suggested putting the update first in the xact as
> a way to reduce aborts.  i have received mail from jean anderson
> at saic pointing out that that it still doesn't eliminate them in her
> app.  so maybe there is a window of vulnerability there after all,
> or maybe the timeout value should be increased.  i will just shut 
> up about this one until i have time to look at it more carefully.  
> (the crowd cheers in the background..:-)

a replace query of the form:

	replace foo (attribute1 = foo.attribute1 + 1)
    
will first do a scan over foo (acquiring a read lock) 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.

> (2) nat and jean have both observed that multiple versions of
> one tuple can be visible at once in the course of an xact.  i 
> think this particular problem is different from what you're 
> describing (this is uncommitted data)..  i think mao fixed the 
> time qual code after 4.1 went out to deal with this.  i sent 
> nat and jean a copy of the new tqual.c to see if this does in 
> fact make their particular problem go away.. (mao!  come back 
> from vienna!)

you should take a close look at how STON87 defines when a tuple is
valid and just fix the code in HeapTupleSatisfiesNow() to reflect this.

> (3) seeing multiple tuples with the same oid after all the updates 
> have committed/aborted is *clearly* wrong, no matter whose data 
> visibility model you use :-)  that's the only reason i mentioned 
> the buffer thing..

i whole-heartedly agree.

> >					retrieve (pg_class.*)
>
> hmm, your sql is showing :-)

just be glad i remembered to use retrieve ;)


jeff (select * from tables;) meredith
mer@miro.com