Re: ctid & updates

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

In response to

Browse pgsql-general by date

  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