Re: BUG #3881: lo_open leaks memory

Tom Lane wrote:
> "Michael Akinde" <michael(dot)akinde(at)met(dot)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.