Re: second DML operation fails with updatable cursor - Mailing list pgsql-hackers

From Tom Lane
Subject Re: second DML operation fails with updatable cursor
Date
Msg-id 5197.1193243694@sss.pgh.pa.us
Whole thread Raw
In response to Re: second DML operation fails with updatable cursor  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: second DML operation fails with updatable cursor
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
>> Tom Lane wrote:
>>> 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.

> I don't like the faith bit.

Well, don't worry, because it doesn't work anyway.  What does seem to
work properly is applying heap_get_latest_tid() to the scan TID obtained
from the cursor.

> FETCH RELATIVE 0 re-fetches the current row according to the manual.

The question is what's the current row, remembering that we've always
defined our cursors as INSENSITIVE.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Feature Freeze date for 8.4
Next
From: Bruce Momjian
Date:
Subject: Re: Feature Freeze date for 8.4