Re: Nested transactions: low level stuff

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