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 1mutC2-0001TM-Uv for pgsql-admin@arkaria.postgresql.org; Wed, 08 Dec 2021 09:24:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mutBV-00036l-S4 for pgsql-admin@arkaria.postgresql.org; Wed, 08 Dec 2021 09:24:21 +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 1mutBV-00036c-Ey for pgsql-admin@lists.postgresql.org; Wed, 08 Dec 2021 09:24:21 +0000 Received: from mail.pscs.co.uk ([178.159.9.185]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mutBM-0002sc-8Z for pgsql-admin@lists.postgresql.org; Wed, 08 Dec 2021 09:24:19 +0000 Authentication-Results: mail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=pscs Received: from lmail.pscs.co.uk ([192.168.150.1]) by mail.pscs.co.uk ([192.168.150.185] running VPOP3) with ESMTPSA (TLSv1.3 TLS_AES_256_GCM_SHA384) for ; Wed, 8 Dec 2021 09:18:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pscs.co.uk; q=dns/txt; s=lmail; h=Content-Type:Message-ID:Date:MIME-Version:Subject:To:References:From :In-Reply-To:Cc:Content-Transfer-Encoding:Reply-to:Sender; t=1638954779; x=1639559579; bh=Lv5nNRWKl14on4ei4DVIprBbu57S7UL5ST3pSXYPJQQ=; b=QdNgDXID22dPLHjmMVewLxk0XsM+LDc0mciyxxVUt1sOIwvzfyds+6+LNIP9z3ZsFkNyKmDj U4+Vw3AKv17W+0QL/aMcL4GT8W0qdrDVqqaDkZFvYZTzv+01qL/WXrs0QuEKvE8kVoIN0OlEa4 0ICP2logQbQDE0awvorfYIrLM= Authentication-Results: lmail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul Received: from [192.168.57.136] ([92.40.188.4] (92.40.188.4.threembb.co.uk)) by lmail.pscs.co.uk ([192.168.150.70] running VPOP3) with ESMTPSA (TLSv1.3 TLS_AES_256_GCM_SHA384); Wed, 8 Dec 2021 09:12:59 -0000 Content-Type: multipart/alternative; boundary="------------jIFscL0f17t1prdE7UNujxjh" Message-ID: Date: Wed, 8 Dec 2021 09:18:22 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: PostgreSQL(v9.6.5) not releasing old/inactive IDLE connections To: pgsql-admin@lists.postgresql.org References: From: Paul Smith In-Reply-To: X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V8.3 - Registered to: PSCS X-Organisation: Paul Smith Computer Services X-VPOP3Tester: 12 345 X-Authenticated-Sender: pscs List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------jIFscL0f17t1prdE7UNujxjh Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 08/12/2021 06:45, Md Arqum Farooqui wrote: > > Hi, > > I'm facing "Too many clients already" error frequently with my > PostgreSQL (v9.6.5) container (i.e. being used along with CKAN > application i.e. A open source data management system >  ), I have observed that PostgreSQL is not > releasing IDLE connections from their end. I have set "max_connetions > = 100" in postgresql. > It is the responsibility of the client software to release connections when they are no longer needed. The server won't just time-out idle connections unless it is told to do so I guess CKAN is keeping a pool of available connections that it can reuse without having to start a new connection. You may be able to set parameters in CKAN so that it kills connections after they have been idle a while. If you're not sure, you really need to ask on a CKAN support forum Or you could use a separate connection pooler (eg PgBouncer) and have CKAN connect to that instead of the database directly. The pooler will then manage reuse across all the client applications, and may be able to timeout idle connections for you. -- Paul Paul Smith Computer Services support@pscs.co.uk - 01484 855800 -- Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 Sign up for news & updates at http://www.pscs.co.uk/go/subscribe --------------jIFscL0f17t1prdE7UNujxjh Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 08/12/2021 06:45, Md Arqum Farooqui wrote:

Hi,

I'm facing "Too many clients already" error frequently with my PostgreSQL (v9.6.5) container (i.e. being used along with CKAN application i.e. A open source data management system ), I have observed that PostgreSQL is not releasing IDLE connections from their end. I have set "max_connetions = 100" in postgresql.

It is the responsibility of the client software to release connections when they are no longer needed. The server won't just time-out idle connections unless it is told to do so

I guess CKAN is keeping a pool of available connections that it can reuse without having to start a new connection. You may be able to set parameters in CKAN so that it kills connections after they have been idle a while. If you're not sure, you really need to ask on a CKAN support forum

Or you could use a separate connection pooler (eg PgBouncer) and have CKAN connect to that instead of the database directly. The pooler will then manage reuse across all the client applications, and may be able to timeout idle connections for you.

-- 
Paul
Paul Smith Computer Services
support@pscs.co.uk - 01484 855800

--

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

--------------jIFscL0f17t1prdE7UNujxjh--