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 1uRCiS-008VOS-0m for pgsql-general@arkaria.postgresql.org; Mon, 16 Jun 2025 16:29:48 +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 1uRCiP-001SgO-TI for pgsql-general@arkaria.postgresql.org; Mon, 16 Jun 2025 16:29:46 +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 1uRCiP-001SgG-FQ for pgsql-general@lists.postgresql.org; Mon, 16 Jun 2025 16:29:46 +0000 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uRCiN-002OWJ-35 for pgsql-general@lists.postgresql.org; Mon, 16 Jun 2025 16:29:45 +0000 Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-747e41d5469so5123343b3a.3 for ; Mon, 16 Jun 2025 09:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750091380; x=1750696180; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=kPObgY93yne1VNjS16BNWWKMoFINXLrTDwXDHq8QdbQ=; b=iYMh4BUVlO77loSeaQ4smiK7++dRZ9oM2MMTkZf6bheXP7sI/jpN0p1RTTLUX+shdm NhOcM9GM9bAdJm7sVU2hmtp2mRj4YU9q0em80iuD+toyaxrqa8yacy+BuOrlDNok7l9Q eYkv+I6EygkYuox6J9T2zer+ziiiyZX1i3pFWJtEEgGmU0Ip+jo55zZG556y/e7b/eJk cvnIIJuCUosQSaflOO5BeKWj1MW9epv8zU4Q/lAPpQxr9nfXL7YLEwzBLqQS3x82Ykgh qMyAjzpmbLhvplW+5oeczcG60w6T8loMMnXlzSEPwsD+fGnxj1N3c9fWpWNbeWdj5BrZ LC1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750091380; x=1750696180; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=kPObgY93yne1VNjS16BNWWKMoFINXLrTDwXDHq8QdbQ=; b=WoXCqH24Mok4c53f5tinWEvbq4V007uSdP4LmP4s4WW9vtFKxM9WJdynEyU6ekkDXU Y7njDNtkD2T3+hOGxkrKADdMztflmRapE5n2Mx+Fsz/473I43Wio9+0ums8bsUcZ/ucY wyvNqrLDIDJ0Auf59t2FDOQ8NHsKQjz8Ui8KI8qlSORO1ay2gpK3Hb+gEyxF3ICFQe5J 5r2SLUYpWs5vHL9oAROG+SJ1cAfcME1ZaCdQKAI6pDNzdQcl4fBewmDXjJu/MZmjcB+P uQglHJ3V5xYa+0yzSfVgxFwbrGqqTsUv1kf4Vezj6sxtVwFHxpIam7+X6DyAzkQiRvBs 5u+A== X-Gm-Message-State: AOJu0YxzOlHLix5v0ssX/bm05KUc3BeD5l+huICesEegzteK3BUdXIrQ xO7YPbjuwPfya0FosWehjPXR43I0+1EM5SWRcmBvaSbMz4Js6EDAwNSZ7eOep8F2CVnXfrBYHvy 09erGHXKJwIgPQWtRl6JTHYSxzmRroLXdBb+b X-Gm-Gg: ASbGncvOaeHF3QO9xbTy79cSWd989YkRv6gGp0uqvFdFXTIBMXcZ5xIg/vaedJm61aQ b/PPRF90NKy4GaZcAsxodb3O1IB+kxyFptZ0lNaX/Lmiefx1eTO/ThASIBU/0zrxkCcXv9rachI zgyZPDYsjzLV6skU9DseEFs+qh5C3hJZRAqk6TozDA7LeqUIuT+Kylcmc= X-Google-Smtp-Source: AGHT+IFJoDSo4j8Ip8KLKCuy7cldYnW7P6ugTxTJgxAyu8uo+fphE2u447Iguo+ho+lL9W4GP3wokiKX/xyjhingcbw= X-Received: by 2002:a05:6a00:3a19:b0:746:2ae9:fc3d with SMTP id d2e1a72fcca58-7489cffb6bbmr12637088b3a.23.1750091380140; Mon, 16 Jun 2025 09:29:40 -0700 (PDT) MIME-Version: 1.0 From: adolfo flores Date: Mon, 16 Jun 2025 10:29:28 -0600 X-Gm-Features: AX0GCFv3DJIaGz1W8zJRTxi4zICNnp3CYSV8hOob9OzdYjmO_RF-AXQyuY6wonY Message-ID: Subject: Getting error "too many clients already" despite having a db connection limit set To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000009add60637b2e74d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000009add60637b2e74d Content-Type: text/plain; charset="UTF-8" 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 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. --00000000000009add60637b2e74d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Team,

I hope you can help me with an issue we= 're experiencing. We have an app running on Kubernetes that opens a hug= e number of connections within a couple of seconds.

The database tha= t the app connects to, is configured with a connection limit of 30% of the = max_connections setting. Despite this limit being set for that database, we= 're seeing the following errors in the PostgreSQL logs:

FATAL: = =C2=A0sorry, too many clients already
FATAL: =C2=A0remaining connection = slots are reserved for roles with the SUPERUSER attribute


Is it = expected behavior to reach the max_connections limit when that app opens ma= ny connections in a short period of time, even if a connection limit is set= for that database and everything else=C2=A0uses no more than 10% of the ma= x_connections?

Or any idea on what could be happening?


Re= gards.

Adolfo F.
--00000000000009add60637b2e74d--