Re: ctid access is slow - Mailing list pgsql-general

From Tom Lane
Subject Re: ctid access is slow
Date
Msg-id 20842.1124855462@sss.pgh.pa.us
Whole thread Raw
In response to Re: ctid access is slow  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: ctid access is slow  (Jeff Eckermann <jeff_eckermann@yahoo.com>)
List pgsql-general
"Jim C. Nasby" <jnasby@pervasive.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

pgsql-general by date:

Previous
From: Michael Fuhr
Date:
Subject: Re: ERROR: database is being accessed by other users
Next
From: Jeff Eckermann
Date:
Subject: Re: ctid access is slow