Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jnYLW-0000aP-5a for pgsql-novice@arkaria.postgresql.org; Tue, 23 Jun 2020 02:07:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jnYLT-0001Vi-Sv for pgsql-novice@arkaria.postgresql.org; Tue, 23 Jun 2020 02:07:31 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jnYLT-0001Vb-MW for pgsql-novice@lists.postgresql.org; Tue, 23 Jun 2020 02:07:31 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jnYLQ-0003hJ-Un for pgsql-novice@postgresql.org; Tue, 23 Jun 2020 02:07:31 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 05N27P5M2114532; Mon, 22 Jun 2020 22:07:25 -0400 From: Tom Lane To: "Bee.Lists" cc: Submit Postgresql Novice Subject: Re: Connections Increasing Slowly In-reply-to: <0345AEA7-346C-452F-B3AE-13ED57818F5F@gmail.com> References: <8A1234E2-D4C3-451F-8F60-901D0D5E0CA5@gmail.com> <2088230.1592856708@sss.pgh.pa.us> <0345AEA7-346C-452F-B3AE-13ED57818F5F@gmail.com> Comments: In-reply-to "Bee.Lists" message dated "Mon, 22 Jun 2020 21:57:44 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <2114530.1592878045.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Mon, 22 Jun 2020 22:07:25 -0400 Message-ID: <2114531.1592878045@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk "Bee.Lists" writes: > On Jun 22, 2020, at 4:11 PM, Tom Lane wrote: >> Another idea, if you suspect that the idle connections are caused >> by firewall timeouts or the like, is to enable more aggressive >> TCP keepalive checking, to ensure the server notices if a client >> isn't there at all anymore. See the tcp_keepalives_* settings. > Who owns the actual connections? The server allows them, the client > requests them. The error I am getting is that the gem I’m using uses a > connection that’s dropped. Hmm. If the client thinks the server dropped the connection, but the server thinks the connection is still live, that smells strongly of network-level disconnects. Does the client let the connection sit idle for more than a minute or two at a time? If so I'd bet that some firewall in between is deciding that the connection is dead and dropping it. Again, setting the server's tcp_keepalives_* settings could help fix that, by ensuring that the network connection sees some traffic regularly. regards, tom lane