Re: Add ETIMEDOUT to ALL_CONNECTION_FAILURE_ERRNOS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jelte Fennema <Jelte(dot)Fennema(at)microsoft(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add ETIMEDOUT to ALL_CONNECTION_FAILURE_ERRNOS
Date: 2021-09-30 14:04:00
Message-ID: 3059801.1633010640@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jelte Fennema <Jelte(dot)Fennema(at)microsoft(dot)com> writes:
> Previously successfully opened TCP connections can still fail on reads
> with ETIMEDOUT. This should be considered a connection failure, so that
> the connection in libpq is marked as CONNECTION_BAD. The reason I got an
> ETIMEDOUT was, because I had set a low tcp_user_timeout in the
> connection string. However, it can probably also happen due to
> keepalive limits being reached.

I'm dubious about the portability of this patch, because we don't
use ETIMEDOUT elsewhere. strerror.c thinks it may not exist,
which is probably overly conservative because POSIX has required
it since SUSv2. The bigger problem is that it's not accounted for in
the WSAxxx mapping done in port/win32_port.h and TranslateSocketError.
That'd have to be fixed for this to behave reasonably on Windows,
I think.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-09-30 14:15:49 Re: non-superusers are allowed to drop the replication user, but are not allowed to alter or even create them, is that ok?
Previous Message Dmitry Dolgov 2021-09-30 13:49:30 Re: pg_stat_statements and "IN" conditions