Re: second DML operation fails with updatable cursor

Simon Riggs <simon(at)2ndquadrant(dot)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