On Mon, 30 Mar 2020 at 17:27, Stefan Knecht wrote:
> I would love to see a fundamental implementation of timeouts at the
> connection level, regardless of activity
By the way, did you try playing with the libpq socket options, such as
tcp_user_timeout?
-- Daniele
On 30/03/20, Stefan Knecht (knecht.ste...@gmail.com) wrote:
> Rory, this is about established connections, not new connections - psycopg2
> already offers a connection timeout, but that is a different thing. I don't
> want to drift too far off topic - but we are already using pgbouncer, and
> the p
>
> Having the client provide general handling for in-flight timeouts would be
> the overall best solution imho.
>
I agree on this: the client should be aware of timeouts, both on connection
and querying.
If we keep the waiting loops in Python and only use non-blocking C
functions I think making
Hi Stefan,
On Mon, 30 Mar 2020, 17:27 Stefan Knecht, wrote:
>
If I may, one thing that has been a constant troublemaker for us - running
> primarily on AWS - is timeouts. I would love to see a fundamental
> implementation of timeouts at the connection level, regardless of activity
> - e.g. in th
Rory, this is about established connections, not new connections - psycopg2
already offers a connection timeout, but that is a different thing. I don't
want to drift too far off topic - but we are already using pgbouncer, and
the problem isn't detected by it, either. I'm not a developer but I belie
On 30/03/20, Stefan Knecht (knecht.ste...@gmail.com) wrote:
> If I may, one thing that has been a constant troublemaker for us - running
> primarily on AWS - is timeouts.
If the issue is disappearing hosts or general connectivity problems,
isn't that problem best dealt with by pg_bouncer?
https:
