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 1uRDBr-008bD8-DI for pgsql-general@arkaria.postgresql.org; Mon, 16 Jun 2025 17:00:11 +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 1uRDBn-001hSV-Ls for pgsql-general@arkaria.postgresql.org; Mon, 16 Jun 2025 17:00:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uRDBn-001hSM-93 for pgsql-general@lists.postgresql.org; Mon, 16 Jun 2025 17:00:07 +0000 Received: from sender4-op-o12.zoho.com ([136.143.188.12]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uRDBk-002Lhf-1d for pgsql-general@lists.postgresql.org; Mon, 16 Jun 2025 17:00:06 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1750093198; cv=none; d=zohomail.com; s=zohoarc; b=I+5hGULUpEOOkMvKobaxzIWx5p05k/RRmkjoG3KXJ0ZnyeymJfHJWfiXIbINlCsc83UBOHr3NNBOBg5NwGZI9+/qtLi4TGtTim54GC+uVScQ/9gPifi2WR24Moia0QbSl0CfQWCFvywhjUb5M6NyDrpgg5y7n9sYE5eGPx2ZGtY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1750093198; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=xnJ7r1IZ4lWtm5Ec9+BiDGxszUarJHjNFTtVCKUkzoA=; b=hJrblxVQFV9Rc6Gm7Nr11jspQjrEcdg/fkX2SF0ahXFBSWvTE0DWFpnqSvXwC9/i42i6/CblfVKDz1IuqFthvo1yha/4Tt/+jglhDjRcmkSQhPu3WErU3i0u04TxjrBp5XT5jGESXAlLg4I+6Aylqm1Cg+dmij+/uSLQ2hEHs6M= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=salesium.com; spf=pass smtp.mailfrom=rwelty@salesium.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1750093198; s=zoho; d=salesium.com; i=rwelty@salesium.com; h=Date:Date:From:From:To:To:Cc:Cc:Message-Id:Message-Id:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Reply-To; bh=xnJ7r1IZ4lWtm5Ec9+BiDGxszUarJHjNFTtVCKUkzoA=; b=BVlw1CvV4jZq0t1+WuOBZy5CyUEJ8lvo0XJakyyT3rBC6p4mzbiicZoOy248/q9A TiWrB7E5vWykPlfMzioEwIXqk/tJuWy+6aXxg5PqPhf09Z2Itu0G5P+KeEcox8YA1qV PGNFoxwNNGvvYTGRtlNBR69qoJGc0c7cojpDx8Kg= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1750093197498562.6957029756115; Mon, 16 Jun 2025 09:59:57 -0700 (PDT) Date: Mon, 16 Jun 2025 12:59:57 -0400 From: Richard Welty To: "Tom Lane" Cc: "adolfo flores" , "pgsql-general" Message-Id: <19779aef09c.f35a7edd116750.8002494421662785732@salesium.com> In-Reply-To: <536522.1750091949@sss.pgh.pa.us> References: <536522.1750091949@sss.pgh.pa.us> Subject: Re: Getting error "too many clients already" despite having a db connection limit set MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_371878_1937745751.1750093197468" Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_371878_1937745751.1750093197468 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable a coding error i've seen from inexperienced devs with little database exper= ience is inattentiveness to how the DB connections were being opened. last time i saw this, a smart young dev with no DB background did not understand the co= st of opening connections and had on the order of 30 php calls to open connect= ions to PostgreSQL in a single page. he did not understand why it was slow. richard ---- On Mon, 16 Jun 2025 12:39:09 -0400 Tom Lane wrote = --- adolfo flores < mailto:adolfoflores2211@gmail.com > writes:=20 > I hope you can help me with an issue we're experiencing. We have an app= =20 > running on Kubernetes that opens a huge number of connections within a=20 > couple of seconds.=20 =20 You need to fix that app to be less unfriendly, or maybe put it behind=20 a connection pooler.=20 =20 > Is it expected behavior to reach the max_connections limit when that app= =20 > opens many connections in a short period of time, even if a connection=20 > limit is set for that database and everything else uses no more than 10% = of=20 > the max_connections?=20 =20 It takes a finite amount of time for a new backend process to figure=20 out which database it's supposed to connect to and then detect whether=20 the per-DB connection limit is exceeded. In the meantime, that=20 session does count against the global limit, so yeah this isn't=20 surprising if the connection arrival rate is high enough.=20 =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0reg= ards, tom lane ------=_Part_371878_1937745751.1750093197468 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
a coding error i've seen from inexperienced devs w= ith little database experience
is inattentiveness to how the = DB connections were being opened. last time i
saw this, a sma= rt young dev with no DB background did not understand the cost
of opening connections and had on the order of 30 php calls to open conne= ctions
to PostgreSQL in a single page. he did not understand = why it was slow.

richard

<= div class=3D"zmail_extra_hr" style=3D"border-top: 1px solid rgb(204, 204, 2= 04); height: 0px; margin-top: 10px; margin-bottom: 10px; line-height: 0px;"= >

---- On Mon, 16 Jun 2025 12:39:09 -0400= Tom Lane <tgl@sss.pgh.pa.us> wrote ---

adolfo fl= ores <ad= olfoflores2211@gmail.com> writes:
> I hope you can help me wi= th an issue we're experiencing. We have an app
> running on Kubernet= es that opens a huge number of connections within a
> couple of seco= nds.

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 connecti= ons in a short period of time, even if a connection
> limit is set f= or that database and everything else uses no more than 10% of
> the = max_connections?

It takes a finite amount of time for a new backen= d 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 me= antime, that
session does count against the global limit, so yeah this = isn't
surprising if the connection arrival rate is high enough.
            r= egards, tom lane




------=_Part_371878_1937745751.1750093197468--