Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c97bd-0007B1-Ac for pgsql-admin@arkaria.postgresql.org; Tue, 22 Nov 2016 09:43:13 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1c97bc-0006O2-Nk for pgsql-admin@arkaria.postgresql.org; Tue, 22 Nov 2016 09:43:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c97bb-0006Nb-G8 for pgsql-admin@postgresql.org; Tue, 22 Nov 2016 09:43:12 +0000 Received: from nm29-vm3.bullet.mail.ir2.yahoo.com ([212.82.97.72]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c97bY-0002bm-1F for pgsql-admin@postgresql.org; Tue, 22 Nov 2016 09:43:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1479807784; bh=WXAyMmB9vecDrquaW/ToAPKxceDiAoQj+LBVsOWcHGI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=gTIZFv+KpB0T9v4FeTC5mWbyxntUynaxHYCFSO2BLCcqTI3ZPSDEF2uaa/b6KP95/m1UoIUPm2Jt7GHJ6bVO0QmPs9OX4wv1Y6toPdWrelnj9oUyTSxZJTJxUEqYAF+ZEDgGaOnlhj6RnZ/KEFCTbGDHbdaH7qr7C/jN/dfRUOKHhQwLPwJDSE0mS3VEQ80aF6Xn2UAwR9W+rJtk5oX9Z8PloYlfIq/PVn+gcUfqQx73Eu3zI9XljwjniSpDYPJBoM90tJwPIn0QFlG6DEOnPq08MbCqMTve5KFZ9PQdNqLxVWyYOWanUMMi3C36Rn9vneJihyacE3KH6FLSHVJk8A== Received: from [212.82.98.55] by nm29.bullet.mail.ir2.yahoo.com with NNFMP; 22 Nov 2016 09:43:04 -0000 Received: from [212.82.98.104] by tm8.bullet.mail.ir2.yahoo.com with NNFMP; 22 Nov 2016 09:43:04 -0000 Received: from [127.0.0.1] by omp1041.mail.ir2.yahoo.com with NNFMP; 22 Nov 2016 09:43:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 260795.52048.bm@omp1041.mail.ir2.yahoo.com X-YMail-OSG: OhtdZGsVM1lfnKtpBwq58YZVvo4YktY64tuun.hga3lMKQYrrJDsN8uF_4i7dA9 3LtOYbJFSukjEujQ0TDnkCrubrqL.oexdRNe.7lfhxdRHE8VZ.y1NG5j.ICLGnOO6vjmfJXrUBGd THHymZq8zQVf69Z9dXQ3SWhjJTA5ohCDMDX3t_EsNCZDLCcZIO4D6fFZEorhWmox1tUtRLNOge.M DITAd1cK_QgdHoedNVYrbtENVIYRaGsCSgZcjChKhgLaVKUIBo2mKN3rdEW9ABeFXnONoOn_ulU_ QHfT4OiPH1nUDMRmRIisSRLkougPLbv_ynOxwrmA8S42EA2.lg0S98D90WWI4.F.hpt7LNcMCxa. eCNaim.2FS1exI_9cna61NixFQQyVYb6eOgBoRdvh_sT2Pkt0uaGuUnnRcJ4kp887Fv3HCvrTv96 ezJsHtHZKUg0c7YqHueQ1RiG3mqsz2paQJIoUwHGSmQqOuBWaMJtCt4iSbpwNe8ERDozGh7u6X.K GNl2LhXXJKDTWa5U444dvryJLLQNRlA-- Received: from jws700020.mail.ir2.yahoo.com by sendmailws108.mail.ir2.yahoo.com; Tue, 22 Nov 2016 09:43:03 +0000; 1479807783.881 Date: Tue, 22 Nov 2016 09:42:58 +0000 (UTC) From: Glyn Astill Reply-To: Glyn Astill To: Sumeet Shukla , pgsql-admin Cc: Rahul Saha Message-ID: <464882906.3185231.1479807778670@mail.yahoo.com> In-Reply-To: References: Subject: Re: Difference between child_life_time and connection_life_time in pgPool MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Length: 2244 X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org > From: Sumeet Shukla >To: pgsql-admin >Cc: Rahul Saha >Sent: Monday, 21 November 2016, 21:47 >Subject: [ADMIN] Difference between child_life_time and connection_life_time in pgPool > > > >Hi, > > >Can someone explain me the difference between child_life_time and connection_life_time parameters in pgpool-II version 3.3.10 (tokakiboshi) > > >I found below on web: >child_life_time: Life of a idle child process in seconds. This will prevent unwanted memory leaks or other problems. > >connection_life_time: Life time for each idle connection in seconds. 0 means the life time is forever. > > > >but I'm unable to understand the difference between idle child process and idle connection. > > You should ask your question on the "pgpool-general" list (pgpool-general@pgpool.net). My understanding was that child_life_time is the amount of time an idle pgpool child process (that is an unused backend) will live for before it is torn down and replaced with a new child porocess. In the past pgpool would from time to time have the odd memory leak bug, and I think this setting was to try and mitigate the impact of such bugs. You shouldn't really worry about it too much on a stable version of pgpool these days I'd have thought. The connection_life_time parameter is the amount of time an idle connection between pgpool and the postgres server will be kept open before disconnecting. A simplified explanation would be to imagine you have a single client connecting via pgpool, that connects every 10 seconds and runs a short lived query; if you set this to 5 seconds then every time your client connected to pgpool, pgpool would have to connect to the postgresql server, and once the client had disconnected from pgpool, pgpool would disconnect from postgresql 5 seconds later. If you were to instead set it to 15 seconds, pgpool would keep the connection to postgresql connection open between your clients connections to pgpool its self as the lifetime would not elapse. The latter being the kind of behaviour people usually want from a connection pooler. You should ask your questions on pgpool-general if you want better quality answers though. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin