Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE - Mailing list pgsql-sql

From Tom Lane
Subject Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE
Date
Msg-id 24728.1196287704@sss.pgh.pa.us
Whole thread Raw
In response to Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE  ("Daniel Caune" <daniel.caune@ubisoft.com>)
Responses Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-sql
"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.

I think you must have somehow got a corrupt-data situation with respect
to the commit status of these rows, but it's not real clear how.
Would you show us the xmin and xmax of the rows, and also the current
transaction counter?  (pg_controldata will give you a close-enough
idea of the latter.)
        regards, tom lane


pgsql-sql by date:

Previous
From: "Daniel Caune"
Date:
Subject: Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE
Next
From: Alvaro Herrera
Date:
Subject: Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE