RE: CURRENT OF cursor without OIDs

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Ian Lance Taylor" <ian(at)airs(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: CURRENT OF cursor without OIDs
Date: 2001-08-08 12:46:10
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA41EB375@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 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 ?
(This might need a function interface to make it reasonably portable to
future
versions)
Of course the only thing you can do if you notice it has changed is bail
out.
But that leaves the question to me on what should actually be done when
the tuple has changed underneath.
I for one would not like the update to succeed if someone else modified
it
inbetween my fetch and my update.

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-08-08 13:45:30 Re: Question about todo item
Previous Message Doug McNaught 2001-08-08 03:25:15 Re: Re: Client Side Connection Pooling