Re: Expansion of our checks for connection-loss errors - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Expansion of our checks for connection-loss errors
Date
Msg-id 2709572.1602253072@sss.pgh.pa.us
Whole thread Raw
In response to Re: Expansion of our checks for connection-loss errors  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: Expansion of our checks for connection-loss errors  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Fujii Masao <masao.fujii@oss.nttdata.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



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Uninitialized var utilized (src/backend/tsearch/spell.c)
Next
From: Tom Lane
Date:
Subject: Re: Uninitialized var utilized (src/backend/tsearch/spell.c)