To: Guillaume Lelarge <guillaume@lelarge.info>
cc: Marc Cousin <mcousin@sigma.fr>, pgsql-admin@postgresql.org
Subject: Re: plpgsql function seems to be leaking memory 
In-reply-to: <486114BF.7040901@lelarge.info> 
References: <200806241056.29589.mcousin@sigma.fr>
	<16759.1214319370@sss.pgh.pa.us> <486114BF.7040901@lelarge.info>
Comments: In-reply-to Guillaume Lelarge <guillaume@lelarge.info>
	message dated "Tue, 24 Jun 2008 17:37:35 +0200"
Date: Tue, 24 Jun 2008 11:48:11 -0400
Message-ID: <18398.1214322491@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Guillaume Lelarge <guillaume@lelarge.info> 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.

			regards, tom lane