<div class="moz-cite-prefix">On 11/16/2015 10:54 PM, Alvaro Herrera wrote:<br /></div><blockquote
cite="mid:20151116195453.GC614468@alvherre.pgsql"type="cite"><pre wrap="">Konstantin Knizhnik wrote:
</pre><blockquote type="cite"><pre wrap="">But you may notice that original TransactionIdSetTreeStatus function is
void
- it is not intended to return anything.
It is called in RecordTransactionCommit in critical section where it is not
expected that commit may fail.
But in case of DTM transaction may be rejected by arbiter. XTM API allows to
control access to CLOG, so everybody will see that transaction is aborted.
But we in any case have to somehow notify client about abort of transaction.
</pre></blockquote><pre wrap="">
I think you'll need to rethink how a transaction commits rather
completely, rather than consider localized tweaks to specific functions.
For one thing, the WAL record about transaction commit has already been
written by XactLogCommitRecord much earlier than calling
TransactionIdCommitTree. So if you were to crash at that point, it
doesn't matter how much the arbiter has rejected the transaction, WAL
replay would mark it as committed. </pre></blockquote><br /> Yes, WAL replay will recover this transaction and try to
markit in CLOG as completed, but ... we have <font face="Arial">caught </font>control over CLOG using XTM.<br /> And
insteadof direct writing to CLOG, DTM will contact arbiter and ask his opinion concerning this transaction. <br /> If
arbiterdoesn't think that it was committed, then it will not be marked as committed in local CLOG.<br /><br /><br
/><blockquotecite="mid:20151116195453.GC614468@alvherre.pgsql" type="cite"><pre wrap=""> Also, what about the
replication
origin stuff and the TransactionTreeSetCommitTsData() call?
I think you need to involve the arbiter earlier, so that the commit
process can be aborted earlier than those things.
</pre></blockquote><br />
