Re: psycopg3: a first report

From: Rory Campbell-Lange <rory(at)campbell-lange(dot)net>
To: Stefan Knecht <knecht(dot)stefan(at)gmail(dot)com>
Cc: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, psycopg(at)postgresql(dot)org
Subject: Re: psycopg3: a first report
Date: 2020-03-30 10:00:21
Message-ID: 20200330100021.GA32517@campbell-lange.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: psycopg

On 30/03/20, Stefan Knecht (knecht(dot)stefan(at)gmail(dot)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

In response to

Browse psycopg by date

  From Date Subject
Next Message Daniele Varrazzo 2020-03-30 10:53:17 Re: psycopg3: a first report
Previous Message Daniele Varrazzo 2020-03-30 09:30:33 Re: psycopg3: a first report