Re: Nested transaction proposal - take N (N > 2) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Nested transaction proposal - take N (N > 2)
Date
Msg-id Pine.OSF.4.58.0403252121560.135305@kosh.hut.fi
Whole thread Raw
In response to Nested transaction proposal - take N (N > 2)  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Re: Nested transaction proposal - take N (N > 2)  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: Nested transaction proposal - take N (N > 2)  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
I haven't seen your patch yet, but the proposal looks good to me.

On Tue, 23 Mar 2004, Alvaro Herrera wrote:

>     Let the currently unused fourth state in pg_clog indicate a
>     committed subtransaction.  In pg_clog there are two bits per
>     transaction, commit and abort, with the following meaning:
>
>      a  c
>      0  0  transaction in progress, the owning backend knows whether
>            it is a main- or a sub-transaction, other backends don't care
>      1  0  aborted, nobody cares whether main- or sub-transaction
>      0  1  committed main-transaction or - with shortcut 2 - a sub-
>            transaction that's known committed to all active transactions
>      1  1  committed sub-transaction, have to look for parent in
>            pg_subtrans

This conflicts with my two-phase commit patch. I'm using the fourth state
to mark transactions that have been prepared (1st. phase) but not yet
committed.

I think I can work around it in my code, so that you can have the fourth
state. I have to keep a list of prepared transactions in memory anyway, I
can use that instead.

> Lock Management
> ---------------
>
> When a subtransaction aborts, it has to release all LWLocks and
> heavyweight locks it's currently holding.  On subtrans commit, all locks
> are held and reassigned to the parent transaction.  Only at main
> transaction commit are all locks released.

I have code for reassigning locks in my two-phase commit patch too. Locks
are reassigned to a special "nobody" pseudo-backend, when a transaction
prepares to commit. We might be able to share some code.

> File deletion, Deferred triggers, Asynchronous notifies
> --------------------------------------------------------
>
> These mechanisms will have to keep lists of items corresponding to each
> subtransaction, and do something special to it on commit or on abort.
> Deftriggers and notifies can be dropped on transaction abort, which is
> very easy if we allocate them in the CommitContext.  On subtrans commit,
> the list of them is reassigned to the parent subtrans.
>
> File deletion is different because we can drop some files on
> subtransaction abort.  At commit, items are reassigned to parent.

I'm looking forward to see your solutions to these issues. I'm facing the
same problems, with the twist that transactions that have been prepared
for commit have to survive shutdowns.

- Heikki



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [PERFORM] fsync method checking
Next
From: Dustin Sallings
Date:
Subject: Re: subversion vs cvs (Was: Re: linked list rewrite)