Re: psycopg3: a first report - Mailing list psycopg

From Rory Campbell-Lange
Subject Re: psycopg3: a first report
Date
Msg-id 20200330100021.GA32517@campbell-lange.net
Whole thread Raw
In response to Re: psycopg3: a first report  (Stefan Knecht <knecht.stefan@gmail.com>)
List psycopg
On 30/03/20, Stefan Knecht (knecht.stefan@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 problem isn't detected by it, either. I'm not a developer but I believe
> the problem is the generic nature of some blocking socket calls, which may
> hang under some odd circumstances, and they remain hanging until some odd
> ssl timeout is reached (15 minutes+ which is a very long time for any
> application to be hanging in limbo, but more so for our own monitoring
> tools which are written in Python).

My apologies for the misunderstanding.

This sounds like the hanging tcp/ip problem one can get with
disappearing web server clients. We've had that problem with mobiles
dropping out presumably because they go out of range, and the provider
not dropping the connection because they might come back.

We deal with this in apache by having a fairly aggressive
KeepAliveTimeout parameter.

Having this problem in one's own stack sounds scary.

I'm very intrigued by Daniele's suggestion that having a per-operation
timeout on the client is achievable.

Rory





psycopg by date:

Previous
From: Daniele Varrazzo
Date:
Subject: Re: psycopg3: a first report
Next
From: Daniele Varrazzo
Date:
Subject: Re: psycopg3: a first report