From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | RE: CURRENT OF cursor without OIDs |
Date: | 2001-08-24 01:15:12 |
Message-ID: | 3705826352029646A3E91C53F7189E32016751@sectorbase2.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > AFAICS, if you are holding an open SQL cursor, it is sufficient
> > to check that ctid hasn't changed to know that you have the
> > same, un-updated tuple. Under MVCC rules, VACUUM will be unable
> > to delete any tuple that is visible to your open transaction,
> > and so new-style VACUUM cannot recycle the ctid.
...
>
> As Tom mentiond once in this thread, I've referred to non-SQL
> cursors which could go across transaction boundaries.
> TIDs aren't that reliable across transactions.
We could avoid reassignment of MyProc->xmin having cursors
opened across tx boundaries and so new-style vacuum wouldn't
remove old tuple versions...
> OIDs and xmin have already lost a part of its nature. Probably
> I have to guard myself beforehand and so would have to mention
> repeatedly from now on that if we switch to an overwriting smgr,
> there's no system item to detect the change of tuples.
So, is tid ok to use for your purposes?
I think we'll be able to restore old tid along with other tuple
data from rollback segments, so I don't see any problem from
osmgr...
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2001-08-24 01:32:44 | Re: CURRENT OF cursor without OIDs |
Previous Message | Tom Lane | 2001-08-24 00:56:20 | Re: Re: [JDBC] New backend functions? [was Re: JDBC changes for 7.2... some questions...] |