Oliver Jowett <[EMAIL PROTECTED]> writes: >> At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I >> think you have missed a bet in that it needs to be possible to issue >> "COMMIT PREPARED gid" for the same gid several times without error.
> Isn't this usually where the GTM would issue "recover" requests to > determine the state of the individual resources involved in the global > transaction, and then only commit/abort the resources that need it? (I > think the equivalent in Heikki's work is a SELECT of the > pg_prepared_xact view) Well, the question is how long must the individual databases retain state with which to answer "recover" requests. I don't like "forever", so I'm proposing that there should be an explicit command to say "you can forget about this gid". Note that this is only really necessary because of Heikki's choice to make the API work in terms of a user-assigned GID. If PREPARE returned the internal XID and then the COMMIT/ROLLBACK PREPARED statements took the XID and not a GID, we could answer subsequent "recover" requests for quite a long time by consulting pg_clog. But then the transaction monitor would have to maintain the map from its GIDs to per-node XIDs, so unless it's going to have such functionality anyway, it's reasonable to ask the database to keep the map. (Either way, you're not going to want to drop the mapping entry until the transaction monitor knows all the commits are done.) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html