>> >> No, the COMMIT returns after the first phase. It can not wait for all >> the foreign servers to complete their second phase > > Hm, it sounds like it's same as normal commit (not 2PC). > What's the difference? > > My understanding is that basically the local server can not return > COMMIT to the client until 2nd phase is completed.
If we do that, the local server may not return to the client at all, if the foreign server crashes and never comes up. Practically, it may take much longer to finish a COMMIT, depending upon how long it takes for the foreign server to reply to a COMMIT message. I don't think that's desirable. > Otherwise the next transaction can see data that is not committed yet > on remote server. 2PC doesn't guarantee transactional consistency all by itself. It only guarantees that all legs of a distributed transaction are either all rolled back or all committed. IOW, it guarantees that a distributed transaction is not rolled back on some nodes and committed on the other node. Providing a transactionally consistent view is a very hard problem. Trying to solve all those problems in a single patch would be very difficult and the amount of changes required may be really huge. Then there are many possible consistency definitions when it comes to consistency of distributed system. I have not seen a consensus on what kind of consistency model/s we want to support in PostgreSQL. That's another large debate. We have had previous attempts where people have tried to complete everything in one go and nothing has been completed yet. 2PC implementation OR guaranteeing that all the legs of a transaction commit or roll back, is an essential block of any kind of distributed transaction manager. So, we should at least support that one, before attacking further problems. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers