Return-Path: aoki
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA27242; Wed, 21 Apr 93 14:45:25 -0700
Message-Id: <9304212145.AA27242@postgres.Berkeley.EDU>
From: aoki@postgres.berkeley.edu (Paul M. Aoki)
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:06:50 -0700 
	     <9304212109.AA26801@postgres.Berkeley.EDU> 
Date: Wed, 21 Apr 93 14:45:38 -0700
Sender: aoki@postgres.Berkeley.EDU
X-Mts: smtp

Jeff Meredith <mer@miro.com> writes:
> it has been argued that the visibility model be changed such that a
> transaction can see the changes of any committed transaction regardless
> of when it starts.  this would solve the above problem, but it turns out
> that it will give you consistency problems.

hi, jeff.

there are several issues here:

(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..:-)

(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!)

(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..

>					retrieve (pg_class.*)

hmm, your sql is showing :-)
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki
