On Sat, Feb 27, 2016 at 1:14 PM, Konstantin Knizhnik <k.knizh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
