Tom Lane wrote:
"Michael Akinde" <michael.akinde@met.no> 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.
