Hi, On 2016/10/04 13:26, Ashutosh Bapat wrote: >>> >>> Why always rollback any dangling transaction? There can be a case that >>> a foreign server has a dangling transaction which needs to be >>> committed because the portions of that transaction on the other shards >>> are committed. >> >> Right, we can heuristically make a decision whether we do COMMIT or >> ABORT on local server. >> For example, if COMMIT PREPARED succeeded on at least one foreign >> server, the local server return OK to client and the other dangling >> transactions should be committed later. >> We can find out that we should do either commit or abort the dangling >> transaction by checking CLOG. > > Heuristics can not become the default behavior. A user should be given > an option to choose a heuristic, and he should be aware of the > pitfalls when using this heuristic. I guess, first, we need to get a > solution which ensures that the transaction gets committed on all the > servers or is rolled back on all the foreign servers involved. AFAIR, > my patch did that. Once we have that kind of solution, we can think > about heuristics.
I wonder if Sawada-san is referring to some sort of quorum-based (atomic) commitment protocol [1, 2], although I agree that that would be an advanced technique for handling the limitations such as blocking nature of the basic two-phase commit protocol in case of communication failures, IOW, meant for better availability rather than correctness. Thanks, Amit [1] https://en.wikipedia.org/wiki/Quorum_(distributed_computing)#Quorum-based_voting_in_commit_protocols [2] http://hub.hku.hk/bitstream/10722/158032/1/Content.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers