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 15:33:07 -0500
Message-ID: <20830.1196281987@sss.pgh.pa.us> (raw)
In-Reply-To: <1E293D3FF63A3740B10AD5AAD88535D2068A67DD@UBIMAIL1.ubisoft.org>
References: <1E293D3FF63A3740B10AD5AAD88535D2068A67DD@UBIMAIL1.ubisoft.org>
"Daniel Caune" <daniel.caune@ubisoft.com> writes:
> I did the following test, removing all the where-clause from the SELECT statement. Every statement completes immediately, i.e. it doesn't block.
I think you left out some critical information, like who else was doing
what to the table.
What it looks like to me is that the third and fourth rows in this view
were live according to your transaction snapshot, but were committed
dead as of current time, and so FOR UPDATE wouldn't return them.
> agoratokens=> select id from "Tokens" where id IN (47, 104, 44, 42) limit 3 for update;
> This time, the statement returns the row where id equals to 44.
No, it returns *some* row where id equals 44. Not necessarily the same
one seen in the seqscan. (I imagine this query is using an index, and
so would visit rows in a different physical order.) Printing the ctid
of the rows would confirm or disprove that theory.
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: <20830.1196281987@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