Re: nested xacts and phantom Xids - Mailing list pgsql-patches

From Alvaro Herrera
Subject Re: nested xacts and phantom Xids
Date
Msg-id 20040622020105.GA7002@dcc.uchile.cl
Whole thread Raw
In response to Re: nested xacts and phantom Xids  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: nested xacts and phantom Xids  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: nested xacts and phantom Xids  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: nested xacts and phantom Xids  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
On Sun, Jun 20, 2004 at 04:37:16PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > Here I present the nested transactions patch and the phantom Xids patch
> > that goes with it.
>
> I looked at the phantom XIDs stuff a bit.  I still have little confidence
> that the concept is correct :-( but here are some comments on the code
> level.

Ok.  I for one think this got much more complex than I had originally
thought it would be.  I agree the changes to Set/Get Xmin/Xmax are way
beyond what one would want, but the alternative would be to spread the
complexity into their callers and I think that would be much worse.

I don't have a lot of confidence in this either.  The patch will be
available in archives if anybody wants to implement this in a cleaner
and safer way; I'll continue working on the rest of the things you
pointed out in the subtransactions patch.

Sadly, something broke in a really strange way between my last cvs
update and today's, because I can't get the patch to initdb.  It
compiles without warnings (and I did make distclean), but there's a
weird bug I'll have to pursue.


Regarding the invalidation messages, what I'm currently looking at is to
add a TransactionId to each message, which will be CurrentTransactionId
for each new message.  When a subxact commits, all its messages are
relabeled to its parent.  When a subxact aborts, all messages labeled
with its TransactionId are locally processed and discarded.  This is
tricky because chunks are prepended to the queue, but it also means we
can stop processing as soon as a message belongs to another transaction.

I think GUC vars are easier: when a variable is about to change value
inside a subtransaction, save the previous value in a list from which it
will be restored if the subtransaction later aborts.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Hay dos momentos en la vida de un hombre en los que no debería
especular: cuando puede permitírselo y cuando no puede" (Mark Twain)


pgsql-patches by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Show encoding in initdb messages
Next
From: Tom Lane
Date:
Subject: Re: nested xacts and phantom Xids