> Oops I'm referring to client side cursors in our ODBC
> driver. We have no cross-transaction cursors yet though
> I'd like to see a backend cross-transaction cursor also.
Ops, sorry.
BTW, what are "visibility" rules for ODBC cross-tx cursor?
No Repeatable reads, no Serializability?
Do you hold s
"Mikheev, Vadim" wrote:
>
> > > 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
> > 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 canno
Tom Lane wrote:
>
> "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> > Hiroshi wrote:
> >> In addtion, xmin wouldn't be so reliable
> >> in the near future because it would be updated to FrozenXID
> >> (=2) by vacuum.
>
> > I thought concurrent vacuum with an open cursor is not at all po
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Hiroshi wrote:
>> In addtion, xmin wouldn't be so reliable
>> in the near future because it would be updated to FrozenXID
>> (=2) by vacuum.
> I thought concurrent vacuum with an open cursor is not at all possible.
> If it were, it would
Hiroshi 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 i
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > GetXmaxRecent() ignores the backend tx_old because it had been
> > committed when VACUUM started and may return the xid > the
> > very old xid of tx_old.
>
> Absolutely not; things would never work if that were true.
> GetXmaxRecen
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Hmm is there any place setting proc->xmin other than
> > the following ?
>
> > [in storage/ipc/sinval.c]
> >if (serializable)
> >MyProc->xmin = snapshot->xmin;
>
> AFAICT that's the only place that sets it.
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Hmm is there any place setting proc->xmin other than
> the following ?
> [in storage/ipc/sinval.c]
>if (serializable)
>MyProc->xmin = snapshot->xmin;
AFAICT that's the only place that sets it. It's cleared to zero during
transa
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> GetXmaxRecent() ignores the backend tx_old because it had been
> committed when VACUUM started and may return the xid > the
> very old xid of tx_old.
Absolutely not; things would never work if that were true.
GetXmaxRecent() returns the oldest TID that
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Yes mainly but I want the verification by OID even in
> > *inside a transaction* cases. For example,
>
> > 1) A backend tx1 fetch a row using cursor.
> > 2) Very old backend tx_old deletes the row and commits.
> > 3) The new VACUUM
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> >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
>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 a
Ian Lance Taylor wrote:
>
[snip]
> > > >
> > > > Yes TID is available and I introduced Tid Scan in order
> > > > to support this kind of implementation. However there
> > > > are some notices.
> > > > 1) Is *FOR UPDATE* cursor allowed in PL/pgSQL ?
> > > >(It doesn't seem easy for me).
> > >
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > > > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > > > Anyhow, I see that there is a move afoot to eliminate mandatory OIDs.
> > > > > My question now is: if there is no OID, is there any comparable way to
> > > > > implement CURRENT OF cursor? B
Ian Lance Taylor wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>
> > > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > > Anyhow, I see that there is a move afoot to eliminate mandatory OIDs.
> > > > My question now is: if there is no OID, is there any comparable way to
> > > > implement
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > Anyhow, I see that there is a move afoot to eliminate mandatory OIDs.
> > > My question now is: if there is no OID, is there any comparable way to
> > > implement CURRENT OF cursor? Basically what is
Tom Lane wrote:
>
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > Anyhow, I see that there is a move afoot to eliminate mandatory OIDs.
> > My question now is: if there is no OID, is there any comparable way to
> > implement CURRENT OF cursor? Basically what is needed is some way to
> > identi
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Anyhow, I see that there is a move afoot to eliminate mandatory OIDs.
> My question now is: if there is no OID, is there any comparable way to
> implement CURRENT OF cursor? Basically what is needed is some way to
> identify a particular row between
19 matches
Mail list logo
