Question concerning XTM (eXtensible Transaction Manager API)

Hello,<br /><br /> Some time ago at PgConn.Vienna we have proposed eXtensible Transaction Manager API (XTM).<br /> The
ideais to be able to provide custom implementation of transaction managers as standard Postgres extensions,<br />
primarygoal is implementation of distritibuted transaction manager.<br /> It should not only support 2PC, but also
provideconsistent snapshots for global transaction executed at different nodes.<br /><br /> Actually, current version
ofXTM API  propose any particular 2PC model. It can be implemented either at coordinator side<br /> (as it is done in
our<a href="https://github.com/postgrespro/pg_tsdtm">pg_tsdtm</a> implementation based on timestamps and not requiring
centralizedarbiter), either by arbiter<br /> (<a href="https://github.com/postgrespro/pg_dtm">pg_dtm</a>). In the last
case2PC logic is hidden under XTM SetTransactionStatus method:<br /><br />      bool
(*SetTransactionStatus)(TransactionIdxid, int nsubxids, TransactionId *subxids, XidStatus status, XLogRecPtr lsn);<br
/><br/> which encapsulates TransactionIdSetTreeStatus in clog.c.<br /> But you may notice that original
TransactionIdSetTreeStatusfunction is void - it is not intended to return anything.<br /> It is called in
RecordTransactionCommitin critical section where it is not expected that commit may fail.<br /> But in case of DTM
transactionmay be rejected by arbiter. XTM API allows to control access to CLOG, so everybody will see that transaction
isaborted. But we in any case have to somehow notify client about abort of transaction.<br /><br /> We can not just
callelog(ERROR,...) in SetTransactionStatus implementation because inside critical section it cause Postgres crash with
panicmessage. So we have to remember that transaction is rejected and report error later after exit from critical
section:<br/><br /><br />         /*<br />          * Now we may update the CLOG, if we wrote a COMMIT record above<br
/>         */<br />         if (markXidCommitted) {<br />             committed = TransactionIdCommitTree(xid,
nchildren,children);<br />         }<br /> ...<br />     /*<br />      * If we entered a commit critical section, leave
itnow, and let<br />      * checkpoints proceed.<br />      */<br />     if (markXidCommitted)<br />     {<br />    
   MyPgXact->delayChkpt = false;<br />         END_CRIT_SECTION();<br />         if (!committed) {<br />            
CurrentTransactionState->state= TRANS_ABORT;<br />             CurrentTransactionState->blockState =
TBLOCK_ABORT_PENDING;<br/>             elog(ERROR, "Transaction commit rejected by XTM");<br />         }<br />    
}<br/><br /> There is one more problem - at this moment the state of transaction is TRANS_COMMIT.<br /> If ERROR
handlerwill try to abort it, then we get yet another fatal error: attempt to rollback committed transaction.<br /> So
weneed to hide the fact that transaction is actually committed in local XLOG.<br /><br /> This approach works but looks
alittle bit like hacker approach. It requires not only to replace direct call of TransactionIdSetTreeStatus with
indirect(though XTM API), but also requires  to make some non obvious changes in RecordTransactionCommit.<br /><br />
Sowhat are the alternatives?<br /><br /> 1. Move RecordTransactionCommit to XTM. In this case we have to copy original
RecordTransactionCommitto DTM implementation and patch it here. It is also not nice, because it will complicate
maintenanceof DTM implementation.<br /> The primary idea of XTM is to allow development of DTM as standard PostgreSQL
extensionwithout creating of specific clones of main PostgreSQL source tree. But this idea will be compromised if we
havecopy&paste some pieces of PostgreSQL code.<br /> In some sense it is even worser than maintaining separate
branch- in last case at least we have some way to perfrtom automatic merge.<br /><br /> 2. Propose some alternative
two-phasecommit implementation in PostgreSQL core. The main motivation for such "lightweight" implementation of 2PC in
pg_dtmis that original mechanism of prepared transactions in PostgreSQL adds to much overhead.<br /> In our benchmarks
wehave found that simple credit-debit banking test (without any DTM) works almost 10 times slower with PostgreSQL 2PC
thanwithout it. This is why we try to propose alternative solution (right now pg_dtm is 2 times slower than vanilla
PostgreSQL,but it not only performs 2PC but also provide consistent snapshots).<br /><br /> May be somebody can suggest
someother solution?<br /> Or give some comments concerning current approach?<br /><br /> Thank in advance, <br />
Konstantin,<br /> Postgres Professional<br /><br />