Manfred Koizar <mkoi-pg@aon.at> 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
