Date: Wed, 28 Nov 2007 22:08:18 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Daniel Caune <daniel.caune@ubisoft.com>, pgsql-sql@postgresql.org
Subject: Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE
Message-ID: <20071129010818.GA5118@alvh.no-ip.org>
References: <1E293D3FF63A3740B10AD5AAD88535D2068A695E@UBIMAIL1.ubisoft.org>
	<24728.1196287704@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <24728.1196287704@sss.pgh.pa.us>
User-Agent: Mutt/1.5.16 (2007-06-11)

Tom Lane wrote:
> "Daniel Caune" <daniel.caune@ubisoft.com> writes:
> > It seems that, in certain condition, row (199,84) is shadowing row
> > (3702,85);
> 
> This would be the expected behavior if row (199,84) were an updated
> version of row (3702,85), but you couldn't see it yet in your current
> transaction snapshot.  A plain SELECT would show the older version
> (the current one according to the snapshot) while SELECT FOR UPDATE
> would show the newest committed version.

Hmm.  We've been studying a case on one customer where xmin/xmax seem to
be corrupted.  It has had ups and downs because I have my doubts about
their storage system, but I'm not completely sure that it can be really
blamed.

This is on 8.1.10.

-- 
Alvaro Herrera       Valdivia, Chile   ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
Major Fambrough: You wish to see the frontier?
John Dunbar: Yes sir, before it's gone.