Re: second DML operation fails with updatable cursor

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