On 2016/10/06 17:45, Ashutosh Bapat wrote: > On Thu, Oct 6, 2016 at 1:34 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote: >> On Thu, Oct 6, 2016 at 1:41 PM, Ashutosh Bapat >> <ashutosh.ba...@enterprisedb.com> wrote: >>>> 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. >> >> Yes, I think 2PC behaves so, please refer to [1]. >> To prevent local server stops forever due to communication failure., >> we could provide the timeout on coordinator side or on participant >> side. > > This too, looks like a heuristic and shouldn't be the default > behaviour and hence not part of the first version of this feature.
At any rate, the coordinator should not return to the client until after the 2nd phase is completed, which was the original point. If COMMIT taking longer is an issue, then it could be handled with one of the approaches mentioned so far (even if not in the first version), but no version of this feature should really return COMMIT to the client only after finishing the first phase. Am I missing something? I am saying this because I am assuming that this feature means the client itself does not invoke 2PC, even knowing that there are multiple servers involved, but rather rely on the involved FDW drivers and related core code handling it transparently. I may have misunderstood the feature though, apologies if so. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers