On Thu, Oct 13, 2016 at 7:37 PM, Ashutosh Bapat
<ashutosh.ba...@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.


Masahiko Sawada
NTT Open Source Software Center

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to