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 1jnYC7-0000AZ-SL for pgsql-novice@arkaria.postgresql.org; Tue, 23 Jun 2020 01:57:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jnYC6-0006sB-Mk for pgsql-novice@arkaria.postgresql.org; Tue, 23 Jun 2020 01:57:50 +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 1jnYC6-0006s4-FE for pgsql-novice@lists.postgresql.org; Tue, 23 Jun 2020 01:57:50 +0000 Received: from mail-qt1-x833.google.com ([2607:f8b0:4864:20::833]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jnYC3-0006AU-TL for pgsql-novice@postgresql.org; Tue, 23 Jun 2020 01:57:49 +0000 Received: by mail-qt1-x833.google.com with SMTP id o38so5604765qtf.6 for ; Mon, 22 Jun 2020 18:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=riSWWjU/hXNBCS5eYbQHjtx/2i5DgK0fTAxq31GhRsI=; b=mfm6b2PAFL7UJbj/OiJ06iU8c6GPnM5BsRKeRAbp4tV4iQVpOQqEpt5arb3G2LFiVn VGSQ0uDintwiZQNFZFUjTTBeM2wwWNUgcL51mkSrR52SKw62sXbWbYJNRNMUd8vsDCB0 V5d//o1bZ4L92mYD4qLwFqke/kyIq1Rnm9rwPVGhnJSV6MTeSrx/UAAyoXvYFs2NEa4e Y01zVfI7ZnZsh/p/6k2qRAH+nfm3gR1IgVKYGTrHWVRi1yd7P9Jc5f3eSRGvGBdzOO/T HIA6IpTIolZr+Ybcuz1LpW/9aZE7Ymn0FkxHN+4kVKqboXDbZbUPkMbjT8z754no319F 3xvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=riSWWjU/hXNBCS5eYbQHjtx/2i5DgK0fTAxq31GhRsI=; b=OLpzGLGVujE3BdDpLK2eP38f88N8Eg51+pYoYZOCXMRt5QCMQTbmBUHHX5wEWfMZSB uX6QKT4+a9TEH0zafR98zmBCpgPqZhSf0Fpw5lIk3YfYLnkjycOcNlxUIcWkQ9M0NQWd i6PA+N9/2+929FTYKTRn7ygPDZd1JzZfcMavjYvp0pQY4NqQmmx9Hrc/WfFgLtw6DQdA g+DSIgw9l4FvqFxoLrDkfn5/7ogTbith9FIEFwjMdHQSYi1UB8ybwohCCEcLD4z67ItC DEAJcQJFGNK8veFKXaj6mXRnzKGJjrywhtz0oN1Z1KD9NoBS/EHGVqOAew23wNAgl+cl wKPw== X-Gm-Message-State: AOAM531pVEVmwxQrIhcisZDD7LP/CSDLA8iGaqwgrBeAS4tW8JY8iQt2 6z7bJlkUsTa3+I/xPKFbKwI= X-Google-Smtp-Source: ABdhPJzzoJ++Et+T2WfhMuPenDaUBEqJx5T6p3OZKgzBhyknwPKGK78Qx7BNcnrq5coyXXB7mXikow== X-Received: by 2002:ac8:387c:: with SMTP id r57mr19988550qtb.144.1592877466983; Mon, 22 Jun 2020 18:57:46 -0700 (PDT) Received: from [192.168.1.4] (pints.com. [206.248.184.17]) by smtp.gmail.com with ESMTPSA id n36sm13031539qtc.35.2020.06.22.18.57.45 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Mon, 22 Jun 2020 18:57:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Connections Increasing Slowly From: "Bee.Lists" In-Reply-To: <2088230.1592856708@sss.pgh.pa.us> Date: Mon, 22 Jun 2020 21:57:44 -0400 Cc: Submit Postgresql Novice Content-Transfer-Encoding: quoted-printable Message-Id: <0345AEA7-346C-452F-B3AE-13ED57818F5F@gmail.com> References: <8A1234E2-D4C3-451F-8F60-901D0D5E0CA5@gmail.com> <2088230.1592856708@sss.pgh.pa.us> To: Tom Lane X-Mailer: Apple Mail (2.3124) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On Jun 22, 2020, at 4:11 PM, Tom Lane wrote: >=20 > Postgres doesn't really think that killing connections is part of its > charter. (There is idle_in_transaction_session_timeout, but that's > there to guard against a specific performance issue, not to kill > non-misbehaving sessions.) >=20 > You should probably think about putting a connection pooler such as > pgbouncer in front of your server. That's a better idea for lots of > low-resource-demand clients than giving them direct server = connections. > And I think you're more likely to find features for killing idle > connections there, too. >=20 > 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. >=20 > regards, tom lane Hi Tom. Who owns the actual connections? The server allows them, the client = requests them. The error I am getting is that the gem I=E2=80=99m using = uses a connection that=E2=80=99s dropped. Actually I should say the = =E2=80=9Cconnection pool=E2=80=9D. The client doesn=E2=80=99t (the gem = author doesn=E2=80=99t elaborate on any of this), and now you=E2=80=99re = saying connections aren=E2=80=99t assumed by the database. =20 It=E2=80=99s been recommended that pg_stat_statements and = pg_stat_activity to see what=E2=80=99s happening. =20 Cheers, Bee