Re: Expansion of our checks for connection-loss errors - Mailing list pgsql-hackers
From | Fujii Masao |
---|---|
Subject | Re: Expansion of our checks for connection-loss errors |
Date | |
Msg-id | 5f5b7511-10ab-d272-a4b3-6cf9abd551c2@oss.nttdata.com Whole thread Raw |
In response to | Expansion of our checks for connection-loss errors (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Expansion of our checks for connection-loss errors
|
List | pgsql-hackers |
On 2020/10/09 4:15, Tom Lane wrote: > Over in the thread at [1], we've tentatively determined that the > reason buildfarm member lorikeet is currently failing is that its > network stack returns ECONNABORTED for (some?) connection failures, > whereas our code is only expecting ECONNRESET. Fujii Masao therefore > proposes that we treat ECONNABORTED the same as ECONNRESET. I think > this is a good idea, but after a bit of research I feel it does not > go far enough. I find these POSIX-standard errnos that also seem > likely candidates to be returned for a hard loss of connection: > > ECONNABORTED > EHOSTUNREACH > ENETDOWN > ENETUNREACH > > All of these have been in POSIX since SUSv2, so it seems unlikely > that we need to #ifdef any of them. (It is in any case pretty silly > that we have #ifdefs around a very small minority of our references > to ECONNRESET :-(.) > > There are some other related errnos, such as ECONNREFUSED, that > don't seem like they'd be returned for a failure of a pre-existing > connection, so we don't need to include them in such tests. > > Accordingly, I propose the attached patch (an expansion of > Fujii-san's) that causes us to test for all five errnos anyplace > we had been checking for ECONNRESET. +1 Thanks for expanding the patch! -#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? > I felt that this was getting to > the point where we'd better centralize the knowledge of what to check, > so the patch does that, via an inline function and an admittedly hacky > macro. I also upgraded some places such as strerror.c to have full > support for these symbols. > > All of the machines I have (even as far back as HPUX 10.20) also > define ENETRESET and EHOSTDOWN. However, those symbols do not appear > in SUSv2. ENETRESET was added at some later point, but EHOSTDOWN is > still not in POSIX. For the moment I've left these second-tier > symbols out of the patch, but there's a case for adding them. I'm > not sure whether there'd be any point in trying to #ifdef them. > > BTW, I took out the conditional defines of some of these errnos in > libpq's win32.h; AFAICS that's been dead code ever since we added > #define's for them to win32_port.h. Am I missing something? > > This seems like a bug fix to me, so I'm inclined to back-patch. +1 Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
pgsql-hackers by date: