Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jIrDA-0007aZ-K7 for psycopg@arkaria.postgresql.org; Mon, 30 Mar 2020 10:00:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jIrD9-0008JL-5B for psycopg@arkaria.postgresql.org; Mon, 30 Mar 2020 10:00:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jIrD8-0008Hg-Pu for psycopg@lists.postgresql.org; Mon, 30 Mar 2020 10:00:02 +0000 Received: from campbell-lange.net ([178.79.140.51]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jIrD2-0003tI-6a for psycopg@postgresql.org; Mon, 30 Mar 2020 10:00:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=campbell-lange.net; s=it; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WXjvgdB/lPUw7KKzzWf26lOpD1z3Qzxy+cmpT1UXXFQ=; b=VY9pAS2Sg4ee10t1NpJOh+vds GS29eSLWGBdX//TUvNN1bg5/jTeKa0SgwCCnUW1JuCTaGckq3U6dl6OBBqv1RhZeZgvpP9gA3amx7 nce59fD7icf0FK9m6mjcES0H31saN0Dl6p+v/2m4qbsnn+bGvuwrPYN7d8hQAXdiq4EjA=; Received: from [217.138.52.158] (helo=rory-t450s) by campbell-lange.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jIrCz-0006GY-O6; Mon, 30 Mar 2020 09:59:53 +0000 Received: from rory by rory-t450s with local (Exim 4.92) (envelope-from ) id 1jIrDR-00005P-SM; Mon, 30 Mar 2020 11:00:21 +0100 Date: Mon, 30 Mar 2020 11:00:21 +0100 From: Rory Campbell-Lange To: Stefan Knecht Cc: Daniele Varrazzo , psycopg@postgresql.org Subject: Re: psycopg3: a first report Message-ID: <20200330100021.GA32517@campbell-lange.net> References: <20200330074917.GA28993@campbell-lange.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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