Re: Nested transactions RFC

Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> TransactionId GetParentXact(TransactionId xnum) uses pg_subtrans to
> find the parent transaction of xnum.

This is not only extremely expensive, but in practice would cause
infinite recursion: any attempt to validate the commit state of a
row in pg_subtrans would result in a recursive attempt to search
pg_subtrans. I don't think we can do table access from inside the
tqual.c routines.

A practical implementation, which would cost little except tuple header
space (and yes I know that won't make you happy) would require 3 fields
instead of 2 for both the min and the max:
transaction ID
subtransaction ID
command ID
First check the transaction ID: if aborted or (in-progress and not
mine), tuple is not visible. Next, if the subtransaction ID is not
zero, similarly check it. Finally, if xid and sub-xid are both mine,
the command ID has to be checked.

In this scenario, subtransactions commit or abort by marking their
pg_clog entries, but no one else will care until the parent transaction
commits. So there is no extra state anywhere except for the stack
of active transaction numbers inside each backend.

Possibly we could use techniques similar to what you already suggested
for cmin/cmax to reduce the amount of physical storage needed for the
six logical fields involved.

regards, tom lane

PS: unfortunately, tuple validity checking is only a small part of what
has to be done to support subtransactions. The really nasty part is
in fixing error recovery inside the backend so that (most) errors can
be dealt with by aborting only the innermost subtransaction.