Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> At the commit time _lo_commit() is called under GlobalMemoryContext to
> destroy IndexScanDesc. So it seems the IndexScanDesc is supposed to be
> created under GlobalMemoryContext. But actually lo_read/lo_write,
> they might create IndexScanDesc also, may not be called under the
> context since no context switching is made with them(I don't know why
> since other LO calls make context switching).
I was noticing that yesterday (I modified be-fsstubs.c to use properly
allocated filehandles in lo_import and lo_export, and added extra
checking for a valid LO handle --- the old code would coredump if
handed a -1 handle, which is not too cool considering that's what it
would get if an app didn't bother to check for lo_open failure...).
It seemed odd that lo_read and lo_write didn't switch contexts like the
other entry points did. But I didn't know enough to risk changing it.
> Possible solutions might be:
> (1) do a context switching in lo_read/lo_write
I agree with this, but I worry a little bit about memory leakage,
because anything allocated in GlobalMemoryContext is not going to get
cleaned up automatically. If lo_read/lo_write call any code that is
sloppy about pfree'ing everything it palloc's, then you'd have a
long-term leakage that would eventually make the backend run out of
memory. But it'd be easy enough to test for that, if you have a test
app that can run the backend through a lot of LO calls.
regards, tom lane