On Tue, Oct 4, 2016 at 1:11 PM, Amit Langote
<Langote_Amit_f8@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, 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.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
