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

From Tom Lane
Subject Re: Two-phase commit
Date
Msg-id 1660.1097106413@sss.pgh.pa.us
Whole thread Raw
In response to Re: Two-phase commit  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List pgsql-hackers
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> I am concerned with a different issue: what issues arise regarding
> snapshots?  Do concurrent xacts see a prepared one as running?  I'm not
> sure but I think so.  So they have to be able to at least get its Xid,
> no?

Hmm, that's a good point.  It seems that uncommitted prepared XIDs
have to be included whenever a Snapshot is manufactured.  That means
we need reasonably fast access to that set of XIDs, which is something
I was thinking we wouldn't need to support.  It's hard to see how to
handle that without some sort of shared-memory data structure listing
those XIDs.

(This also blows out of the water the present
preallocated-space-for-the-XID-lists memory allocation in GetSnapshot,
but that was never more than the most marginal hack anyway.)

> As soon as you have that stored somewhere, you have to ensure that an
> arbitrary number of Xids, or better, snapshots, have to be somewhere.
> The "100" concept does not impress me either.  So if you can have an
> arbitrary number of snapshots, you can as well have an arbitrary number
> of WITH HOLD open cursors, without the ugly Materialize node.
> Am I right?

Nope.  Snapshots are not the reason we have to materialize WITH HOLD
cursors.  Locks are.  I suppose you could think about treating a WITH
HOLD cursor like an uncommitted prepared transaction, but I'm not sure
it's worth the overhead.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Oliver Jowett
Date:
Subject: Re: Two-phase commit
Next
From: Oliver Jowett
Date:
Subject: Re: Two-phase commit