Manfred Koizar <[EMAIL PROTECTED]> writes: > If we set XMIN/MAX_IS_COMMITTED in a tuple header, we have to replace > a sub-transaction xid in xmin or xmax respectively with the > main-transaction xid at the same time. Otherwise we'd have to look > for the main xid, whenever a tuple is touched.
This worries me --- it changes a safe operation (OR'ing in a commit bit) into an unsafe one that requires exclusive lock on the page containing the tuple. I'm also concerned that we'd now need a WAL entry to record the xid change (are we dependent on this change occurring for correctness? or is it only performance?) Perhaps it would be better to leave the tuple-commit bit unset until we have been able to change the clog state to 01 ("committed to everyone"). > Tom: >> I think it would be preferable to use only three states: active, >> aborted, committed. > Con: Needs subtrans tree navigation from parent to child. But only in the backend owning the transaction; there's no need for shared state that allows it. > Sorry for the long post. Would you prefer such kind of stuff on a web > page and just a short note with the URL to the list? No. This way it gets into the list archives. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org