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
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 |