From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Caune <daniel.caune@ubisoft.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE
Date: Wed, 28 Nov 2007 17:08:24 -0500
Message-ID: <24728.1196287704@sss.pgh.pa.us> (raw)
In-Reply-To: <1E293D3FF63A3740B10AD5AAD88535D2068A695E@UBIMAIL1.ubisoft.org>
References: <1E293D3FF63A3740B10AD5AAD88535D2068A695E@UBIMAIL1.ubisoft.org>
"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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, daniel.caune@ubisoft.com
Subject: Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE
In-Reply-To: <24728.1196287704@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox