| From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | t-ishii(at)sra(dot)co(dot)jp, postgres <hackers(at)postgreSQL(dot)org> |
| Subject: | Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc |
| Date: | 1999-05-10 00:58:06 |
| Message-ID: | 199905100058.JAA00486@ext16.sra.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > 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.
Yes, I thought about that too. Maybe we could destroy the
GlobalMemoryContext in lo_close() if no LO descriptor exists any more.
Of course this would not prevent the memory leakage if a user forget
to call lo_close, but it's of the user's responsibility anyway.
---
Tatsuo Ishii
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 1999-05-10 01:05:20 | Re: [HACKERS] vacuum slowness |
| Previous Message | Bruce Momjian | 1999-05-10 00:54:27 | Re: [HACKERS] parser enhancement request for 6.5 |