From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: nested transactions |
Date: | 2002-12-04 16:54:30 |
Message-ID: | aj4suuscm1qvfjp2d8mk4u5qb9ocdl96ev@4ax.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)candle(dot)pha(dot)pa(dot)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 ...
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-12-04 17:00:25 | Re: big text field -> message type 0x44 |
Previous Message | Lee Kindness | 2002-12-04 16:50:14 | Re: PQnotifies() in 7.3 broken? |