>Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> I couldn't run your program since I don't have test data. So I made a
>> small test program to make sure if the problem caused by LO (It's
>> stolen from test/examples/testlo.c). In the program, ~4k LO is read
>> for 10000 times in a transaction. The backend process size became a
>> little bit bigger, but I couldn't see any problem you mentioned.
>
>I tried the same thing, except I simply put a loop around the begin/end
>transaction part of testlo.c so that it would create and access many
>large objects in a single backend process. With today's sources I do
>not see a 'ShmemAlloc: out of memory' error even after several thousand
>iterations. (But I do not know if this test would have triggered one
>before...)
>
>What I do see is a significant backend memory leak --- several kilobytes
>per cycle.
>
>I think the problem here is that inv_create is done with the palloc
>memory context set to the private memory context created by lo_open
>... and this memory context is never cleaned out as long as the backend
>survives. So whatever junk data might get palloc'd and not freed during
>the index creation step will just hang around indefinitely. And that
>code is far from leak-free.
>
>What I propose doing about it is modifying lo_commit to destroy
>lo_open's private memory context. This will mean going back to the
>old semantics wherein large object descriptors are not valid across
>transactions. But I think that's the safest thing anyway. We can
>detect the case where someone tries to use a stale LO handle if we
>zero out the LO "cookies" array as a side-effect of lo_commit.
>
>Comments? Objections?
Then why should we use the private memory context if all lo operations
must be in a transaction?
--
Tatsuo Ishii