Re: Two-phase commit

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)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