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?
regards, tom lane
