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 1uRDZx-008g9R-PO for pgsql-general@arkaria.postgresql.org; Mon, 16 Jun 2025 17:25:06 +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 1uRDZv-001v48-Pp for pgsql-general@arkaria.postgresql.org; Mon, 16 Jun 2025 17:25:04 +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 1uRDWk-001qtd-4n for pgsql-general@lists.postgresql.org; Mon, 16 Jun 2025 17:21:47 +0000 Received: from fout-b4-smtp.messagingengine.com ([202.12.124.147]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uRDWh-002OuJ-2d for pgsql-general@lists.postgresql.org; Mon, 16 Jun 2025 17:21:46 +0000 Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfout.stl.internal (Postfix) with ESMTP id 6305111400B1; Mon, 16 Jun 2025 13:21:41 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Mon, 16 Jun 2025 13:21:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1750094501; x=1750180901; bh=V3t9sWbi5dLctumDm0FZFn994gta/joZIIBA2iG6TzA=; b= U9dgW3rutsR1oAb0rZV0m/PCBImSGg8jf2IcLGyaHOWthO6OjIGycUoZ2O60qjuv QQ373iTGatSvlDRU1zpkGyAmaai9EbtVNTmiZTdt3j/44QkE3CSN5xgd4SsUqmcC mjyaXWcu8n7GKnqsRiQpSzmJCTbtxeG3Gvgfod1o5imEWFoVGzTQxhPtOkg19QBC kwd3qdI23NS8gT0CQnSUa0t0VRz1Ip4zS9o3YNKLDrdTL37vdUjJfs532h+WkWD7 Ex4Yhpvk8ePJVNHthU/+xR7OJ6yw/8yTVOQq6Hmgmy1/icn/jtOHuWNlcdUW07sK DUZUk3r4rwDivELvOVcaMQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1750094501; x=1750180901; bh=V 3t9sWbi5dLctumDm0FZFn994gta/joZIIBA2iG6TzA=; b=q39A9K1nCKsdSQkmf tAYY0omGlmvHSSkImfZdxN9mA1bBxaQhr9Nuv9Mxtta8sJsYPq8cABIGRZt6yOGY rlC23WrnnhOTF8SNf9SaLErwt8ytP7KpI8eD6w4TQwgH5cNfn5qWKN/HKlMpkNjK WH48ORi23lTcUxpFEJ/L8C1NP1CqM/v0esdOERYozOPHIzPcLvahwUhpQAIECRtD AOP1HmrDDBIaw74UipmTxv5rUi/1dGfjtVR1ViP3deFG7n5gf+N1ClaZ7dFVbZ2X 02J1dDH8Op5dUEm0OnOWCSsjqmXYSWYB1raJ9ysekWhKEHuMajfxrP+90kcjC5Sc awc2w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddvjedujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertddtvdej necuhfhrohhmpeetughrihgrnhcumfhlrghvvghruceorggurhhirghnrdhklhgrvhgvrh esrghklhgrvhgvrhdrtghomheqnecuggftrfgrthhtvghrnhepffelgeeifefgveduhedt hfekuedtffejveegffegjeevtdehgfduieetfeehjeehnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomheprggurhhirghnrdhklhgrvhgvrhesrghk lhgrvhgvrhdrtghomhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpd hrtghpthhtoheprgguohhlfhhofhhlohhrvghsvddvuddusehgmhgrihhlrdgtohhmpdhr tghpthhtohepphhgshhqlhdqghgvnhgvrhgrlheslhhishhtshdrphhoshhtghhrvghsqh hlrdhorhhg X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 16 Jun 2025 13:21:40 -0400 (EDT) Message-ID: <484c43a4-962d-44ed-af87-e5abde63bd04@aklaver.com> Date: Mon, 16 Jun 2025 10:21:39 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Getting error "too many clients already" despite having a db connection limit set To: adolfo flores , pgsql-general@lists.postgresql.org References: Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 6/16/25 09:29, adolfo flores wrote: > Hello Team, > > 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. > > The database that the app connects to, is configured with a connection > limit of 30% of the max_connections setting. Despite this limit being I am not understanding the above. The connection limit from the database side is going to be the value for max_connections. It is not clear to me what "... connection limit of 30% of the max_connections setting" is referring to? I suggest providing the actual numbers you are working with as well as the locations where the numbers are being set. > set for that database, we're seeing the following errors in the > PostgreSQL logs: > > FATAL:  sorry, too many clients already > FATAL:  remaining connection slots are reserved for roles with the > SUPERUSER attribute > > > 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? > > Or any idea on what could be happening? > > > Regards. > > Adolfo F. -- Adrian Klaver adrian.klaver@aklaver.com