On 29.06.2011 23:07, Simon Riggs wrote:
> My understanding is that if the TM requests rollback of a transaction
> and then the database crashes before it can reply, the TM may request
> rollback a second time. If the first rollback did actually remove the
> transaction this then replies that the transaction is unknown. So
> XAER_RMERR is exactly the wrong error in some cases of 42704.
Well, if the transaction has been rolled back, it's clearly not in
prepared state anymore, so XAER_RMERR seems appropriate and the TM
shouldn't get upset about that. However, the situation is more ambiguous
if the TM issues COMMIT PREPARED and the connection is broken before
receiving a reply. It will retry, and if the the COMMIT succeeded the
first time, the TM will get XAER_RMERR on the second call. That's more
serious.
I believe some (all?) other databases have yet another transaction state
to handle that. After committing a transaction, the database still
remembers the transaction ID and the fact that it was successfully
committed. If the TM doesn't receive a reply to commit, it can reconnect
and check the status to see if the commit succeeded. The transaction is
forgotten about only after the TM sends another 'forget' command. Maybe
we need to implement that in PostgreSQL, too.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com