Re: CURRENT OF cursor without OIDs

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема Re: CURRENT OF cursor without OIDs
Дата
Msg-id 3B71D11C.4D79601F@tpf.co.jp
обсуждение исходный текст
Ответ на RE: CURRENT OF cursor without OIDs  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
Список pgsql-hackers
Zeugswetter Andreas SB SD wrote:
> 
> >    There could be DELETE operations for the tuple
> >    from other backends also and the TID may disappear.
> >    Because FULL VACUUM couldn't run while the cursor
> >    is open, it could neither move nor remove the tuple
> >    but I'm not sure if the new VACUUM could remove
> >    the deleted tuple and other backends could re-use
> >    the space under such a situation.
> 
> If you also save the tuple transaction info (xmin ?) during the
> select in addition to xtid, you could see whether the tupleslot was
> reused ?

I think TID itself is available for the purpose as long as
PostgreSQL uses no overwrite storage manager. If the tuple
for a saved TID isn't found, the tuple may be update/deleted.
If the tuple is found but the OID is different from the saved
one, the space may be re-used. If we switch to an overwriting
storage manager, TID would be no longer transient and we need
another item like xmin to detect the change of rows.
I agree with you that detecting the change of rows is very
critical and xmin may be needed in the future.

regards,
Hiroshi Inoue


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: To be 7.1.3 or not to be 7.1.3?
Следующее
От: Hiroshi Inoue
Дата:
Сообщение: Re: CURRENT OF cursor without OIDs