Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 13E12650F6E for ; Tue, 24 Jun 2008 12:29:42 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 09338-03-2 for ; Tue, 24 Jun 2008 12:29:26 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from gslimes3.sigma.fr (mx.sigma.fr [194.50.39.191]) by postgresql.org (Postfix) with ESMTP id 73D7A650ED3 for ; Tue, 24 Jun 2008 12:29:15 -0300 (ADT) Received: from gsw3mes2.groupesigma.fr (unknown [192.168.1.70]) by gslimes3.sigma.fr (Postfix) with ESMTP id 18729347EC for ; Tue, 24 Jun 2008 17:29:11 +0200 (CEST) Received: from marc.sigma.fr ([89.195.0.5]) by gsw3mes2.groupesigma.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 17:29:10 +0200 From: Marc Cousin Organization: Sigma Informatique To: pgsql-admin@postgresql.org Subject: Re: plpgsql function seems to be leaking memory Date: Tue, 24 Jun 2008 17:29:09 +0200 User-Agent: KMail/1.9.9 References: <200806241056.29589.mcousin@sigma.fr> <16759.1214319370@sss.pgh.pa.us> In-Reply-To: <16759.1214319370@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806241729.09998.mcousin@sigma.fr> X-OriginalArrivalTime: 24 Jun 2008 15:29:10.0984 (UTC) FILETIME=[0CEE0C80:01C8D60F] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200806/206 X-Sequence-Number: 29544 On Tuesday 24 June 2008 16:56:10 Tom Lane wrote: > Marc Cousin writes: > > I'm having a problem with plpgsql functions leaking memory. > > Your example shows absolutely no memory leak here, in either 8.3.3 > or CVS HEAD. > > > I see the postgresql process growing from 8MB to about 400 MB during this > > run... > > What do you have shared_buffers set to? I think you might be getting > fooled by top's treatment of shared memory (ie, it starts to count > shared pages after the process touches them for the first time). > > regards, tom lane I'm seeing this with ps aux, you're (almost) right... And I've been wasting your time. At the begining : postgres 23305 39.2 0.8 1275484 31208 ? Rs 17:07 0:18 postgres: postgres test [local] idle in transaction Then after a few seconds : postgres 23305 39.2 0.8 1275484 31208 ? Rs 17:07 0:18 postgres: postgres test [local] idle in transaction The RSS column is growing ... Here it is only a test, but I've been having it get to more that 500MB on the real use case, and it got me worried... shared_buffers is at 1GB... So in fact, the problem is linked to RSS containing some shared memory... And that this growing memory is because the process has put all those modified blocks in the shared buffers... I've confirmed that with doing the inserts out of plpgsql, and it's also the same if I select the process... And I never noticed it before ... It all started with a plperl procedure and I was afraid I had a leak in it ... :) Sorry to have wasted your time and thanks a lot ... Regards.