On Thu, Oct 13, 2016 at 7:37 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: >>> >>> If we are successful in COMMITTING foreign transactions during >>> post-commit phase, COMMIT message will be returned after we have >>> committed all foreign transactions. But in case we can not reach a >>> foreign server, and request times out, we can not revert back our >>> decision that we are going to commit the transaction. That's my answer >>> to the timeout based heuristic. >> >> IIUC 2PC is the protocol that assumes that all of the foreign server live. > > Do you have any references? Take a look at . The first paragraph > itself mentions that 2PC can achieve its goals despite temporary > failures.
I guess that It doesn't mention that 2PC can it by ignoring temporary failures. Even by waiting for the crashed server revives, 2PC can achieve its goals. >> In case we can not reach a foreign server during post-commit phase, >> basically the transaction and following transaction should stop until >> the crashed server revived. > > I have repeatedly given reasons why this is not correct. You and Amit > seem to repeat this statement again and again in turns without giving > any concrete reasons about why this is so. > >> This is the first place to implement 2PC >> for FDW, I think. The heuristically determination approach I mentioned >> is one of the optimization idea to avoid holding up transaction in >> case a foreign server crashed. >> >>> I don't see much point in holding up post-commit processing for a >>> non-responsive foreign server, which may not respond for days >>> together. Can you please elaborate a use case? Which commercial >>> transaction manager does that? >> >> For example, the client updates a data on foreign server and then >> commits. And the next transaction from the same client selects new >> data which was updated on previous transaction. In this case, because >> the first transaction is committed the second transaction should be >> able to see updated data, but it can see old data in your idea. Since >> these is obviously order between first transaction and second >> transaction I think that It's not problem of providing consistent >> view. > > 2PC doesn't guarantee this. For that you need other methods and > protocols. We have discussed this before.  > At any rate, I think that it would confuse the user that there is no guarantee that the latest data updated by previous transaction can be seen by following transaction. I don't think that it's worth enough to immolate in order to get better performance. Providing atomic visibility for concurrency transaction would be supported later. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers