On Thu, Jun 29, 2006 at 01:39:51AM +0300, Hannu Krosing wrote: > And anyway, ctid is a usable unique row identifier only within read-only > transactions, or not ?
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. In READ COMMITTED mode, the tuple is rechecked for visibility and if it's invisible, the ctid chain is followed to find the visible one (which may not necessarily be the last one). 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. That's what the vacuum lock is for. > Is it correct to assume, that only one row version can be in process of > being modified at any one time? No, different transactions may be updating differing versions, depending on what was visible at the time. In serialisable transactions you'll get a serialisation failure though, and for read committed, the query will be rerun for the latest version of the tuple. One thing I am confused about, currently the ctid chain follows tuple history so that transactions can find the latest version of any tuple, even if the key fields have changed. This proposal breaks that, I'm not sure how important that is though. > Tom - what do you think of the other related idea, that of reusing dead > index entries ? I'd like to know about this too, including ideas about truncating tuples to just the header. Have a nice day. -- Martijn van Oosterhout <email@example.com> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
Description: Digital signature