On Tue, Oct 4, 2016 at 8:29 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Tue, Oct 4, 2016 at 1:11 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> On 2016/10/04 16:10, Ashutosh Bapat wrote: >>>>> 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 meant that we could determine it heuristically only when remote server >>>> crashed in 2nd phase of 2PC. >>>> For example, what does the local server returns to client when no one >>>> remote >>>> server returns OK to local server in 2nd phase of 2PC for more than >>>> statement_timeout seconds? Ok or error? >>>> >>> >>> The local server doesn't wait for the completion of the second phase >>> to finish the currently running statement. Once all the foreign >>> servers have responded to PREPARE request in the first phase, the >>> local server responds to the client. Am I missing something? >> >> PREPARE sent to foreign servers involved in a given transaction is >> *transparent* to the user who started the transaction, no? That is, user >> just says COMMIT and if it is found that there are multiple servers >> involved in the transaction, it must be handled using two-phase commit >> protocol *behind the scenes*. So the aforementioned COMMIT should not >> return to the client until after the above two-phase commit processing has >> finished. > > 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. Otherwise the next transaction can see data that is not committed yet on remote server. > , which can take > quite long (or never) if one of the servers has crashed in between. > >> >> Or are you and Sawada-san talking about the case where the user issued >> PREPARE and not COMMIT? > > I guess, Sawada-san is still talking about the user issued PREPARE. > But my comment is applicable otherwise as well. > Yes, I'm considering the case where the local server tries to COMMIT but the remote server crashed after the local server completes 1st phase (PREPARE) on the all remote server. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
