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".
As I understand it, you don't need to keep state for committed txns, it's only the prepared-but-not-yet-resolved txns that you have to respond to a recover request with.
Then it seems like we already have a "forget about this GID" command for prepared transactions: ROLLBACK PREPARED.
Probably the next question is, do we want a database-side timeout on how long prepared txns can stay alive before being summarily rolled back?
-O
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
