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

Heikki Linnakangas wrote:
> 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.

I think the big question is whether other backends have to see your
status bits for the transaction. Nested transactions require global
backend visibility. If your's doesn't, then you are better off doing it
in local memory.

I would like to get the nested transaction work already coded into CVS
so you can continue on your 2-phase commit work and we get get that
in too soon.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073