[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-bugs
Subject:    Re: [BUGS] BUG #6365: Memory leak in insert and update
From:       Havasvölgyi_Ottó <havasvolgyi.otto () gmail ! com>
Date:       2011-12-30 2:43:37
Message-ID: CAOryeA05jLm2ojLL+NoOcboqwfKu0cNzMJHjZRT+FgqpJMtM_g () mail ! gmail ! com
[Download RAW message or body]

Thanks for the quick response. Linux's top fooled me quite a bit.
Excuse me for the false report.

Best regards,
Otto


2011/12/29 Tom Lane <tgl@sss.pgh.pa.us>

> havasvolgyi.otto@gmail.com writes:
> > The following bug has been logged on the website:
> > Bug reference:      6365
> > Logged by:          Otto Havasv=F6lgyi
> > Email address:      havasvolgyi.otto@gmail.com
> > PostgreSQL version: 9.1.2
> > Operating system:   Win XP SP2 x86; Linux Debian 2.6.32 kernel x64
> > Description:
>
> > The bug can be reproduced with pgbench:
>
> I see no memory leak with this example.
>
> I suspect you are being fooled by tools that report shared memory as
> being used by a process only after it first touches a given page of
> shared memory ("top" on Linux does that, for example).  This will cause
> the apparent memory consumption of any long-lived backend to increase
> until it has touched every available shared buffer.  But that's not a
> leak, just an artifact of the reporting tool.  You can confirm for
> yourself that that's what's happening by reducing shared_buffers to
> a few megabytes and observing that reported memory usage increases up
> to that much and then stops growing.
>
> On Linux, I find that watching the "VIRT" column of top output is a
> far more reliable guide to whether a memory leak is actually occuring.
> Can't offer any suggestions as to what to use on Windows.
>
>                        regards, tom lane
>

[Attachment #3 (text/html)]

Thanks for the quick response. Linux&#39;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">&lt;<a \
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt;</span><br> <blockquote \
class="gmail_quote" style="margin:0pt 0pt 0pt 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>

&gt; The following bug has been logged on the website:<br>
&gt; Bug reference:      6365<br>
&gt; Logged by:          Otto Havasvölgyi<br>
&gt; Email address:      <a \
href="mailto:havasvolgyi.otto@gmail.com">havasvolgyi.otto@gmail.com</a><br> &gt; \
PostgreSQL version: 9.1.2<br> &gt; Operating system:   Win XP SP2 x86; Linux Debian \
2.6.32 kernel x64<br> &gt; Description:<br>
<br>
&gt; 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 first touches a given page of<br>
shared memory (&quot;top&quot; on Linux does that, for example).  This will cause<br>
the apparent memory consumption of any long-lived backend to increase<br>
until it has touched every available shared buffer.  But that&#39;s not a<br>
leak, just an artifact of the reporting tool.  You can confirm for<br>
yourself that that&#39;s what&#39;s happening by reducing shared_buffers to<br>
a few megabytes and observing that reported memory usage increases up<br>
to that much and then stops growing.<br>
<br>
On Linux, I find that watching the &quot;VIRT&quot; column of top output is a<br>
far more reliable guide to whether a memory leak is actually occuring.<br>
Can&#39;t offer any suggestions as to what to use on Windows.<br>
<br>
                        regards, tom lane<br>
</blockquote></div><br>



[prev in list] [next in list] [prev in thread] [next in thread]