Re: Expansion of our checks for connection-loss errors

Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> writes:
> On 2020/10/09 4:15, Tom Lane wrote:
>> -#ifdef ECONNRESET
>> - case ECONNRESET:
>> + case ALL_CONNECTION_LOSS_ERRNOS:
>> printfPQExpBuffer(&conn->errorMessage,
>> libpq_gettext("server closed the connection unexpectedly\n"
>> "\tThis probably means the server terminated abnormally\n"
>> "\tbefore or while processing the request.\n"));

> This change causes the same error message to be reported for those five errno.
> That is, we cannot identify which errno is actually reported, from the error
> message. But I just wonder if it's more helpful for the troubleshooting if we,
> for example, append strerror() into the message so that we can easily
> identify errno. Thought?

Hmm, excellent point. While our code response to all these errors
should be the same, you are right that that doesn't extend to emitting
identical error texts. For EHOSTUNREACH/ENETDOWN/ENETUNREACH, we
should say something like "connection to server lost", without claiming
that the server crashed. It is less clear what to do with ECONNABORTED,
but I'm inclined to put it in the network-problem bucket not the
server-crash bucket, despite lorikeet's behavior. Thoughts?

This also destroys the patch's idea that switch statements should be
able to handle these all alike. If we group things as "ECONNRESET means
server crash and the others are all network failures", then I'd be
inclined to leave the ECONNRESET cases alone and just introduce
new infrastructure to recognize all the network-failure errnos.

regards, tom lane