On Sat, Feb 27, 2016 at 1:14 PM, Konstantin Knizhnik
<k.knizhnik@postgrespro.ru> wrote:
> We do not try to preserve transaction commit order at all nodes.
> But in principle it can be implemented using XTM API: it allows to redefine
> function which actually sets transaction status. pg_dtm performs 2PC here.
> And in principle it is possible to enforce commits in any particular order.
That's encouraging.
> Concerning CSNs, may be you are right and it is not correct to use this
> notion in this case. Actually there are many "CSNs" involved in transaction
> commit.
Perhaps we should distinguish "commit sequence number" from "apply
sequence number"? I really think we need to differentiate the
order to be applied from the order previously committed in order to
avoid long-term confusion. Calling both "CSN" is going to cause
not only miscommunication but muddled thinking, IMO.
> First of all each transaction is assigned local CSN (timestamp) when it is
> ready to commit. Then CSNs of all nodes are exchanged and maximal CSN is
> chosen.
> This maximum is writen as final transaction CSN and is used in visibility
> check.
Is this an implementation of some particular formal technique? If
so, do you have a reference to a paper on it? I get the sense that
there has been a lot written about distributed transactions, and
that it would be a mistake to ignore it, but I have not (yet)
reviewed the literature for it.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company