From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <janwieck(at)yahoo(dot)com> |
Cc: | "Joshua b(dot) Jore" <josh(at)greentechnologist(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: ctid & updates |
Date: | 2002-06-04 23:03:00 |
Message-ID: | 19781.1023231780@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jan Wieck <janwieck(at)yahoo(dot)com> writes:
> Tom Lane wrote:
>> There's a function called something like currtid that takes the
>> CTID of the possibly-obsoleted row and returns the CTID of its latest
>> updated version. I believe this is exported because the ODBC driver
>> uses it, so it's unlikely to go away, even though AFAIR it's not
>> documented anywhere. A risk of using it is that CTID of an updated
>> row cannot be trusted for very long --- once VACUUM has come by,
>> you might find that CTID reassigned to some other row entirely.
> But it should be safe within the transaction that did the
> update, right?
Sure; VACUUM won't risk deleting tuples that were visible as of the
start of the oldest open transaction, so anything that you found earlier
in the current transaction will surely still be there, even if it's not
the latest committed version anymore. I wouldn't trust a CTID older
than the current transaction, however.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-06-04 23:15:59 | Re: View vs. Statement Query Plan |
Previous Message | Glen Parker | 2002-06-04 22:25:16 | Char = varchar |