Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uRCrb-008XHr-NP for pgsql-general@arkaria.postgresql.org; Mon, 16 Jun 2025 16:39:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uRCrZ-001Wqf-Og for pgsql-general@arkaria.postgresql.org; Mon, 16 Jun 2025 16:39:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uRCrZ-001WqP-Ds for pgsql-general@lists.postgresql.org; Mon, 16 Jun 2025 16:39:14 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uRCrX-002OaN-2N for pgsql-general@lists.postgresql.org; Mon, 16 Jun 2025 16:39:13 +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 55GGd9N7536523; Mon, 16 Jun 2025 12:39:09 -0400 From: Tom Lane To: adolfo flores cc: pgsql-general@lists.postgresql.org Subject: Re: Getting error "too many clients already" despite having a db connection limit set In-reply-to: References: Comments: In-reply-to adolfo flores message dated "Mon, 16 Jun 2025 10:29:28 -0600" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <536521.1750091949.1@sss.pgh.pa.us> Date: Mon, 16 Jun 2025 12:39:09 -0400 Message-ID: <536522.1750091949@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk adolfo flores writes: > I hope you can help me with an issue we're experiencing. We have an app > running on Kubernetes that opens a huge number of connections within a > couple of seconds. You need to fix that app to be less unfriendly, or maybe put it behind a connection pooler. > Is it expected behavior to reach the max_connections limit when that app > opens many connections in a short period of time, even if a connection > limit is set for that database and everything else uses no more than 10% of > the max_connections? It takes a finite amount of time for a new backend process to figure out which database it's supposed to connect to and then detect whether the per-DB connection limit is exceeded. In the meantime, that session does count against the global limit, so yeah this isn't surprising if the connection arrival rate is high enough. regards, tom lane