Thanks for the quick response. Linux's top fooled me quite a bit.<br />Excuse me for the false report.<br /><br />Best
regards,<br/>Otto<br /><br /><br /><div class="gmail_quote">2011/12/29 Tom Lane <span dir="ltr"><<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span><br/><blockquote class="gmail_quote" style="margin:0pt
0pt0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><a
href="mailto:havasvolgyi.otto@gmail.com">havasvolgyi.otto@gmail.com</a>writes:<br /> > The following bug has been
loggedon the website:<br /> > Bug reference: 6365<br /> > Logged by: Otto Havasvölgyi<br /> >
Emailaddress: <a href="mailto:havasvolgyi.otto@gmail.com">havasvolgyi.otto@gmail.com</a><br /> > PostgreSQL
version:9.1.2<br /> > Operating system: Win XP SP2 x86; Linux Debian 2.6.32 kernel x64<br /> > Description:<br
/><br/> > The bug can be reproduced with pgbench:<br /><br /></div>I see no memory leak with this example.<br /><br
/>I suspect you are being fooled by tools that report shared memory as<br /> being used by a process only after it
firsttouches a given page of<br /> shared memory ("top" on Linux does that, for example). This will cause<br /> the
apparentmemory consumption of any long-lived backend to increase<br /> until it has touched every available shared
buffer. But that's not a<br /> leak, just an artifact of the reporting tool. You can confirm for<br /> yourself that
that'swhat's happening by reducing shared_buffers to<br /> a few megabytes and observing that reported memory usage
increasesup<br /> to that much and then stops growing.<br /><br /> On Linux, I find that watching the "VIRT" column of
topoutput is a<br /> far more reliable guide to whether a memory leak is actually occuring.<br /> Can't offer any
suggestionsas to what to use on Windows.<br /><br /> regards, tom lane<br
/></blockquote></div><br/>