On Friday 27 July 2007 Alvaro Herrera's cat, walking on the keyboard, wrote:
> Consider an open cursor; you open it and leave it there. Then you
> delete something from the table. Then you read from the cursor. The
> deleted row must be in the cursor.
Thanks fot these details. Now a few other questions come into my mind (I hope
not to bother you guys!).
In chapter 49 of the documentation (index access) I read that an index stores
pointers to any version of the tuple that is present in the database. Now I
remember that the t_ctid field of the HeapTupleHeaderData points to the newer
versione of a tuple (if exists) and that it is possible to follow the t_ctid
to get the newer tuple version. Now since a new version tuple is stored at
the end of a table, chances are that the tuple is stored into another page
that the older one. If this is right, the index is required to know exactly
in which page a tuple version is, rather then following the t_ctid link, thus
what is the purpose of such chain?
The second question is why the index returns all the tuple version without
considering time (I guess MVCC) constraints? What are the problems of
evaluationg the xmin,xmax stuff within the index amget methods? Maybe this is
not done due to concurrency issues?
Third, I read about not valid MVCC snapshots (e.g., SnapshotNow). What is the
meaning of such "strange" snapshots? Because postgresql should always
guarantee at least read committed isolation, and thus this should be done
thru MVCC.....
Thanks,
Luca
---------------------------(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
