Re: PG wire protocol question - Mailing list pgsql-general

From Albe Laurenz
Subject Re: PG wire protocol question
Date
Msg-id A737B7A37273E048B164557ADEF4A58B53850D5C@ntex2010i.host.magwien.gv.at
Whole thread Raw
In response to PG wire protocol question  (Boszormenyi Zoltan <zboszor@pr.hu>)
Responses Re: PG wire protocol question
Re: PG wire protocol question
List pgsql-general
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.

The problem - that the server may commit a transaction, but the client
never receives the server's response - is independent of whether
two-phase commit is used or not.

This is not a problem of PostgreSQL, it is a generic problem of communication.

What would be the alternative?
That the server has to wait for the client to receive the commit response?
But what if the client received the message and the server or the network
go down before the server learns of the fact?
You see that this would lead to an infinite regress.

Yours,
Laurenz Albe

pgsql-general by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: FIRST_VALUE argument must appear in group by?
Next
From: "Charles Clavadetscher"
Date:
Subject: Re: Ascii Elephant for text based protocols - Final function proposal