Re: BUG #3881: lo_open leaks memory
От | Tom Lane |
---|---|
Тема | Re: BUG #3881: lo_open leaks memory |
Дата | |
Msg-id | 8597.1200936253@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #3881: lo_open leaks memory (Michael Akinde <michael.akinde@met.no>) |
Ответы |
Re: BUG #3881: lo_open leaks memory
Re: BUG #3881: lo_open leaks memory |
Список | pgsql-bugs |
Michael Akinde <michael.akinde@met.no> writes: > I use the following script to create a test table. For > /tmp/oidfile.temp, I use "FAQ_farsi" from the PostgreSQL installation > (about 140kb). Okay, I ran this with about 900MB of shared buffers (about as much as I thought I could make it without descending into swap hell ...) and there is no memory leak that I can see. What I *do* see is that the process size as reported by "top" quickly jumps to 900MB plus and then sits there. This is not a memory leak though, it is just a side effect of the way "top" reports usage of shared memory. Basically, a shared buffer starts getting charged against a given process the first time that process touches that buffer. Your test case involves reading a lot of blocks of pg_largeobject and that results in touching a lot of buffers. So basically I don't see a problem here. If you are noticing a performance issue in this area, it may indicate that you have shared_buffers set too large, ie, using more RAM than the machine can really afford to spare. That leads to swapping which drives performance down. regards, tom lane
В списке pgsql-bugs по дате отправления: