> > And anyway, ctid is a usable unique row identifier only within
> > read-only transactions, or not ?
actually for as long as no vacuum comes along. This would change
with SITC. (Maybe it would help to only reuse old versions of the same
row,
then anybody holding a ctid would at least be still looking at a version
of
the same row, and should thus be able to follow the update chain)
> Err, no. The ctid is the only identifer of a tuple in any
> case. When you do a delete, the tuple to be deleted is
> indicated by the ctid field which has been passed up from the
> base table through the rest of the query. When you reach the
> top the ctid better refer to the same tuple or you'll delete
> the wrong one. UPDATE is the same.
For all these purposes you will be holding the ctid of a visible
(to someone) tuple. Those don't qualify for a new SITC tuple anyway.
> For all intents and purposes, the CTID of tuple can't change
> unless you're 100% certain no-one is using it in any way.
For all I know, noone is using dead tuples except for visibility
lookup. We would need to make sure that other backends see the new
tuple eighter as dead or txopen as long as the contents are not valid.
I think we could do that without a vacuum lock on platforms that support
4 byte atomic operations.
Andreas
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
