Re: ctid access is slow

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: Jeff Eckermann <jeff_eckermann(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: ctid access is slow
Date: 2005-08-24 03:51:02
Message-ID: 20842.1124855462@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> I believe that's not necessarily true. If you select a tuple and it's
> ctid and it's updated more than once with a vacuum in-between I believe
> it could end up back in the same position, which would mean the same
> ctid.

This is the reason for the recommendation that you don't trust a TID for
longer than one transaction. If you select a row and see it has TID
such and such, and then later try to fetch/update/delete that row by
TID, the worst that can happen is that you'll not find the row because
some other xact has already updated or deleted it. You can not find
a different row in the TID slot, because VACUUM will not have removed
a row that is possibly still visible to your transaction. (VACUUM
has no idea whether you're running under SERIALIZABLE rules or not,
and so it takes the conservative approach that any row you could ever
possibly have seen as good is still interesting.) But this guarantee
only lasts as long as your current transaction.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Eckermann 2005-08-24 03:56:02 Re: ctid access is slow
Previous Message Michael Fuhr 2005-08-24 02:37:33 Re: ERROR: database is being accessed by other users