Simon Riggs <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
