Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id D7130650F00 for ; Thu, 26 Jun 2008 12:49:15 -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 45578-02 for ; Thu, 26 Jun 2008 12:49:06 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sd-2317.dedibox.fr (sd-2317.dedibox.fr [88.191.17.192]) by postgresql.org (Postfix) with ESMTP id 27C13650F18 for ; Thu, 26 Jun 2008 12:48:53 -0300 (ADT) Received: from [192.168.10.64] (ASte-Genev-Bois-153-1-4-194.w83-112.abo.wanadoo.fr [83.112.66.194]) by sd-2317.dedibox.fr (Postfix) with ESMTP id BA62AA44E; Thu, 26 Jun 2008 17:48:51 +0200 (CEST) Message-ID: <4863BA63.80501@lelarge.info> Date: Thu, 26 Jun 2008 17:48:51 +0200 From: Guillaume Lelarge User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Tom Lane CC: Marc Cousin , pgsql-admin@postgresql.org Subject: Re: plpgsql function seems to be leaking memory References: <200806241056.29589.mcousin@sigma.fr> <16759.1214319370@sss.pgh.pa.us> <486114BF.7040901@lelarge.info> <18398.1214322491@sss.pgh.pa.us> In-Reply-To: <18398.1214322491@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/220 X-Sequence-Number: 29558 Tom Lane a écrit : > Guillaume Lelarge writes: >> Tom Lane a écrit : >>> 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). > >> That's what I thought at first when I saw Marc's email. I tried his >> example many times, with different values for shared_buffers. RSS column >> climbs until it reaches more or less the shared_buffers configuration. >> But, if I launch another psql, this process will have a much lower value >> on the RSS column. Shouldn't it get the RSS at the same value, even when >> the process starts ? > > No, that's exactly the point. Linux top includes in a process's > reported size its actual private space, plus however many pages of > shared memory that process has physically accessed so far. So any PG > backend that's doing a material amount of table access is going to show > an RSS that starts low and creeps up to roughly the size of your shared > memory block, quite independently of what its actual private space usage > is. It's just a matter of how many buffers it has had occasion to use. > > This is all pretty OS-dependent. Some systems don't count shared memory > at all (HPUX seems not to), and some other ones report a separate total > for shared memory so that you can mentally subtract it. > Forgot to thank you for the answer... Thanks :) -- Guillaume. http://www.postgresqlfr.org http://dalibo.com