Re: Nested transaction proposal - take N (N > 2)

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Nested transaction proposal - take N (N > 2)
Date: 2004-03-25 19:32:05
Message-ID: Pine.OSF.4.58.0403252121560.135305@kosh.hut.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dustin Sallings 2004-03-25 20:03:36 Re: subversion vs cvs (Was: Re: linked list rewrite)
Previous Message Josh Berkus 2004-03-25 19:10:55 Re: [HACKERS] fsync method checking