On Wed, May 18, 2016 at 5:05 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote:
> 2016-05-17 15:29 keltezéssel, Albe Laurenz írta:
>>
>> Boszormenyi Zoltan wrote:
>>>
>>> it was a long time I have read this list or written to it.
>>>
>>> Now, I have a question. This blog post was written about 3 years ago:
>>> https://aphyr.com/posts/282-jepsen-postgres
>>>
>>> Basically, it talks about the client AND the server as a system
>>> and if the network is cut between sending COMMIT and
>>> receiving the answer for it, the client has no way to know
>>> whether the transaction was actually committed.
>>>
>>> The client connection may just timeout and a reconnect would
>>> give it a new connection but it cannot pick up its old connection
>>> where it left. So it cannot really know whether the old transaction
>>> was committed or not, possibly without doing expensive queries first.
>>>
>>> Has anything changed on that front?
>>
>> That blog post seems ill-informed - that has nothing to do with
>> two-phase commit.
>
> Not quite. That would mean constantly sending an ack that the other
> received the last ack, which would be silly.
>
> If the network connection is cut, the client should be able to
> reconnect to the old backend and query the last state and continue
> where it left, maybe confirming via some key or UUID that it was
> indeed the client that connected previously.
I agree. It's the server's job to make sure itself is consistent. If
the client is suspicious it may have lost the ack for whatever reason,
it needs to verify against the database that the transaction
succeeded. This is an application problem, not a protocol problem.
merlin