Skip site navigation (1) Skip section navigation (2)

Re: second DML operation fails with updatable cursor

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Dharmendra Goyal" <dharmendra(dot)goyal(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: second DML operation fails with updatable cursor
Date: 2007-10-24 13:49:51
Message-ID: 1822.1193233791@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Dharmendra Goyal" <dharmendra(dot)goyal(at)gmail(dot)com> writes:
> If i do update and delete operations on a row pointed by cursor's current
> then only first operation succeeds, second operation fails.

Hm, by "fails" you mean "does nothing", right?

The reason for this is that WHERE CURRENT OF is implemented as if it
were WHERE tid = <something>, and historically we've taken that to mean
the specific tuple at that exact TID.  After there's been an update
already, the tuple at that TID is no longer live to your transaction,
and so the tid-search fails.  To make this work as the spec requires,
we'd have to be willing to follow the tuple update chain to find the
currently-live instance of the row.

While I've not tried this, I think we could fix it by having nodeTidscan
use SnapshotAny instead of the query snapshot when fetching a tuple for
CurrentOf (but not otherwise, so as to not change the behavior of WHERE
tid = <something>).  We'd essentially be taking it on faith that the
CurrentOf gave us a TID that was live earlier in the transaction, and
so is still safe to fetch.  I think everything else would just fall out
if the initial heap_fetch weren't rejecting the tuple.

Comments anyone?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-10-24 13:58:40
Subject: Re: Feature Freeze date for 8.4
Previous:From: Marko KreenDate: 2007-10-24 13:38:14
Subject: Re: Feature Freeze date for 8.4

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group