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  (Michael Akinde <michael.akinde@met.no>)
Re: BUG #3881: lo_open leaks memory  (Michael Akinde <michael.akinde@met.no>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #3881: lo_open leaks memory
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #3883: Autovacuum deadlock with truncate?