Tom Lane wrote:
"Michael Akinde" <[EMAIL PROTECTED]> writes:
Description: lo_open leaks memory
Hmm, I cannot replicate any memory leak with your example.
I'm testing 8.2.6 (well, really 8.2 branch tip) not 8.2.5, but I
don't recall that there were any recent fixes in this area.
Perhaps there is some contributing factor you didn't mention?
No doubt. I'm not sure what it would be, though.
The table gridvalue is of course a table with an attribute gridoid OID,
containing at least 150,000 objects (in our own case, I simply run it on
our valuetable which contains 4 million 90K binary objects). The problem
doesn't occur with "fake" OIDs - and (at least from what I have seen) -
neither does it occur if if it is just 150,000 copies of the same OID.
The testcase displays the behavior on a 64-bit debian etch setup, with
Postgres 8.2.5. The testcase given (running on our value table), easily
chews up 1.9 GB of memory in no time. The table in question is fairly
large (20 or so attributes) and fairly heavily indexed, but we don't
seem to be able to chew up main memory in the same way, without the
lo_open call.
I'll try to build a more complete test case for you (incl. table and
blob generation), but am a bit hampered by the limits on my workstation
at the moment. It seems though as if the problem does not crop up with
small files (at least, the attempts I've done so far to recreate the
testcase with small volumes of synthetic data haven't recreated the
problem), so this might take a while. I'll try to get something ready by
monday.
Regards,
Michael A.
begin:vcard
fn:Michael Akinde
n:Akinde;Michael
org:Meteorologisk Institutt, Norge;IT
adr;quoted-printable:;;Gaustadall=C3=A9en 30D;Oslo;;0313;Norge
email;internet:[EMAIL PROTECTED]
tel;work:22963379
tel;cell:45885379
x-mozilla-html:FALSE
url:http://www.met.no
version:2.1
end:vcard
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
