Re: pgsql: postgres_fdw: reestablish new connection if cached one is detect
От | Tom Lane |
---|---|
Тема | Re: pgsql: postgres_fdw: reestablish new connection if cached one is detect |
Дата | |
Msg-id | 2461600.1602164840@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: postgres_fdw: reestablish new connection if cached one is detect (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: pgsql: postgres_fdw: reestablish new connection if cached one is detect
Re: pgsql: postgres_fdw: reestablish new connection if cached one is detect |
Список | pgsql-committers |
Fujii Masao <masao.fujii@oss.nttdata.com> writes: >> Therefore, the easy fix is to make libpq mark the connection as >> CONNECTION_BAD even in ECONNABORTED, like we do in ECONNRESET. > Patch attached. This patch also changes errcode_for_socket_access() > so that it uses ERRCODE_CONNECTION_FAILURE rather than > ERRCODE_INTERNAL_ERROR as sqlerrorcode in ECONNABORTED case > like ECONNRESET. Is this sane? Some digging around on the net suggests that Windows will only return WSAECONNRESET for the case where it gets a TCP RST packet from the remote host. Other cases of TCP connection loss (e.g. timeout) are reported as WSAECONNABORTED. I think that our code generally only expects ECONNRESET to be reported for a lost connection. Based on this info, we clearly need to handle ECONNABORTED as being equivalent to that. I don't see any reason why we'd care to distinguish the two cases. So it seems like (a) we'd better make sure that ECONNABORTED is recognized anyplace that we're testing for ECONNRESET, and (b) that seems like a back-patchable bug fix, independently of the immediate issue. On the other hand, it seems a bit odd that we've not recognized this issue long since. Maybe the preference for ECONNABORTED only exists on a few Windows versions? I've not checked your patch in detail. regards, tom lane
В списке pgsql-committers по дате отправления: