From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | t-ishii(at)sra(dot)co(dot)jp |
Cc: | postgres <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc |
Date: | 1999-05-09 15:53:01 |
Message-ID: | 2076.926265181@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-05-09 16:02:40 | Re: [HACKERS] Re: Number of parameters in a sql function |
Previous Message | Bruce Momjian | 1999-05-09 15:51:58 | Re: [GENERAL] inet and cidr type problems |