Re: Two-phase commit issues - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Two-phase commit issues
Date
Msg-id 28014.1116471600@sss.pgh.pa.us
Whole thread Raw
In response to Re: Two-phase commit issues  (Alvaro Herrera <alvherre@surnet.cl>)
List pgsql-hackers
Alvaro Herrera <alvherre@surnet.cl> writes:
> On Wed, May 18, 2005 at 07:29:38PM -0400, Tom Lane wrote:
>> What I had in mind was that each prepared xact's state file would just
>> list the MultiXactIds it belongs to.

> Hm, this assumes the transaction knows what MultiXactIds it belongs to.
> This is not true, is it?  I'm not sure how to find that out.

[ thinks about that for a bit... ]  I had been thinking we could just
track it locally in each backend, but that won't do for the case where
someone adds you to a MultiXactId without your knowledge.  Seems like
we'd have to actually scan the contents of pg_multixact?  Yech.

> Maybe the restriction could be lighter -- what if the prepared
> transaction inserts tuples on a temp table, for example.  It's
> inconsistent, I think, that a temp table could have tuples on it that
> suddenly appear when some other backend commits my prepared transaction.

Yeah, there are all sorts of interesting problems there :-(.  I think
we'd be best off to punt for the moment.  I think we could enforce that a
transaction being PREPAREd hasn't touched any temp tables at all, by
checking that it holds no locks on such tables.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Learning curves and such (was Re: pgFoundry)
Next
From: Tom Lane
Date:
Subject: Re: Learning curves and such (was Re: pgFoundry)