On Thu, Oct 13, 2016 at 7:37 PM, Ashutosh Bapat
<ashutosh.bapat@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 [1]. 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. [2]
>
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
