Re: Nested transactions: low level stuff

Manfred Koizar <mkoi-pg(at)aon(dot)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