Tom Lane wrote:
>> Now let's say that I issue my next query and the network connection
>> recovers in the process. I happily start retrieving results again, but
>> are they only results for the new query, or do I go through the
>> remaining
>> results of the last query first?
>
> I don't think there is a unique answer to that, without a whole lot of
> assumptions about the nature of the failure and the behavior of the
> network transport layer. Did the backend see any send() failures?
> Did the transport layer permanently lose any data already given to it,
> or just delay transmission?
Well, I'm sort of assuming that if some data was actually lost, libpq
would call that a synchronization error and give up on the connection. So
I'm talking specifically about the case where no data was lost, but an
error was returned by the network stack and the error later went away.
> On the whole I think the odds of re-syncing successfully are pretty bad,
> and you'd be best off to pull the plug and start a new connection if you
> see any networking failure.
I guess that makes sense. But how do I know that the failure is a
networking failure and not, say, an SQL-level failure? In my program, I
mean, without human intervention?
Jeroen
