Re: nested transactions - Mailing list pgsql-hackers

[Sorry for the delay.  I'm a bit busy these days.]

On Fri, 29 Nov 2002 15:57:17 -0500 (EST), Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
>> BTW, I think this *forces* us to replace the sub xid with the
>> respective main xid in a tuple header, when we set
>> XMIN/MAX_IS_COMMITTED.  Otherwise we'd have to look for the main xid,
>> whenever a tuple is touched.
>
>Sorry, I don't follow this.

Probably because we've mixed up several proposals.  I'll try to pick
them apart below.

>As far as I know, we will set the subxid on
>the tuple so we can independently mark the xact as aborted without
>revisiting all the tuples.

Yes.

>Once it is committed/rolled back,

These cases are completely different.  If a (main or sub-) transaction
is rolled back, its effects are invisible to all transactions; this
status is immediately effective and final.  OTOH a subtransaction
commit is only tentative.  It becomes effective when the main
transaction commits.  (And the subtransaction's status turns to
aborted, when the main transaction aborts.)

>I see no
>need to lookup the parent, and in fact we could clear the clog parent
>xid offset so there is no way to access the parent anymore.

While a subtransaction is seen as "tentatively committed" other
transactions have to look up its parent to find out its effective
status.

Proposal A was:  Never show "tentatively committed" to outside
transactions.  This would require neither any new flags in tuple
headers or in pg_clog nor a globally visible pg_subtrans structure.
But it only works, if we can commit a main transaction and all its
subtransactions atomically, which is only possible if we hold a long
lasting lock.  Did we agree that we don't want this?

All other solutions require a parent xid lookup at least during the
time span while a subtransaction is marked "tentatively committed" and
not yet known to be "finally committed".  IIRC we have three proposals
how the "tentatively committed" status can be shown to outside
transactions:

(B) Two flags in the tuple header (one for xmin, one for xmax) telling
us "the xid is a subtransaction".  I don't like this very much,
because it's not in Normal Form: "is a subtransaction" is NOT a
property of a tuple.  OTOH we can declare it a denormalization for
performance reasons (we don't have to look up the parend xid, if the
flag is not set.)

(C) Explicitly use the fourth possible status in pg_clog for
"tentatively committed".  (Performance hack:  replace with "finally
committed" as soon as the xid is visible to all active transactions.)

(D) Only one kind of "committed" in pg_clog; always look for a parent
in pg_subtrans; for performance reasons integrate pg_subtrans into
pc_clog.

Tom brought up the snapshot visibility problem which applies to B, C,
and D.

While each of these proposals can be implemented (relatively) straight
forward, the Black Art is:  When and how can we modify the stored
state to avoid repeated parent xid lookups?  We'll find out ...

ServusManfred