Re: second DML operation fails with updatable cursor

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: second DML operation fails with updatable cursor
Дата
Msg-id 5197.1193243694@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: second DML operation fails with updatable cursor  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: second DML operation fails with updatable cursor  (Heikki Linnakangas <heikki@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Feature Freeze date for 8.4
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Feature Freeze date for 8.4