Re: BUG #6365: Memory leak in insert and update
От | Merlin Moncure |
---|---|
Тема | Re: BUG #6365: Memory leak in insert and update |
Дата | |
Msg-id | CAHyXU0zD6OJcWwB2MgQjQ2z9fnz=7iBH65AYy3US9F9r9M4ovQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #6365: Memory leak in insert and update (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #6365: Memory leak in insert and update
|
Список | pgsql-bugs |
On Thu, Dec 29, 2011 at 2:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > havasvolgyi.otto@gmail.com writes: >> The following bug has been logged on the website: >> Bug reference: =A0 =A0 =A06365 >> Logged by: =A0 =A0 =A0 =A0 =A0Otto Havasv=F6lgyi >> Email address: =A0 =A0 =A0havasvolgyi.otto@gmail.com >> PostgreSQL version: 9.1.2 >> Operating system: =A0 Win XP SP2 x86; Linux Debian 2.6.32 kernel x64 >> Description: > >> The bug can be reproduced with pgbench: > > I see no memory leak with this example. > > I suspect you are being fooled by tools that report shared memory as > being used by a process only after it first touches a given page of > shared memory ("top" on Linux does that, for example). =A0This will cause > the apparent memory consumption of any long-lived backend to increase > until it has touched every available shared buffer. =A0But that's not a > leak, just an artifact of the reporting tool. =A0You can confirm for > yourself that that's what's happening by reducing shared_buffers to > a few megabytes and observing that reported memory usage increases up > to that much and then stops growing. > > On Linux, I find that watching the "VIRT" column of top output is a > far more reliable guide to whether a memory leak is actually occuring. > Can't offer any suggestions as to what to use on Windows. This is by the way a FAQ: http://wiki.postgresql.org/wiki/FAQ#Why_does_PostgreSQL_use_so_much_memory.= 3F merlin
В списке pgsql-bugs по дате отправления: