From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Akinde <michael(dot)akinde(at)met(dot)no> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #3881: lo_open leaks memory |
Date: | 2008-01-21 17:24:13 |
Message-ID: | 8597.1200936253@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Michael Akinde <michael(dot)akinde(at)met(dot)no> writes:
> I use the following script to create a test table. For
> /tmp/oidfile.temp, I use "FAQ_farsi" from the PostgreSQL installation
> (about 140kb).
Okay, I ran this with about 900MB of shared buffers (about as much as I
thought I could make it without descending into swap hell ...) and there
is no memory leak that I can see. What I *do* see is that the process
size as reported by "top" quickly jumps to 900MB plus and then sits
there. This is not a memory leak though, it is just a side effect of
the way "top" reports usage of shared memory. Basically, a shared
buffer starts getting charged against a given process the first time
that process touches that buffer. Your test case involves reading a lot
of blocks of pg_largeobject and that results in touching a lot of
buffers.
So basically I don't see a problem here. If you are noticing a
performance issue in this area, it may indicate that you have
shared_buffers set too large, ie, using more RAM than the machine
can really afford to spare. That leads to swapping which drives
performance down.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christian Schröder | 2008-01-21 17:39:08 | Re: (possible) bug with constraint exclusion |
Previous Message | Tom Lane | 2008-01-21 16:23:39 | Re: BUG #3881: lo_open leaks memory |