Re: BUG #6365: Memory leak in insert and update
| От | Tom Lane | 
|---|---|
| Тема | Re: BUG #6365: Memory leak in insert and update | 
| Дата | |
| Msg-id | 27188.1325189417@sss.pgh.pa.us обсуждение исходный текст  | 
		
| Ответ на | BUG #6365: Memory leak in insert and update (havasvolgyi.otto@gmail.com) | 
| Ответы | 
                	
            		Re: BUG #6365: Memory leak in insert and update
            		
            		 Re: BUG #6365: Memory leak in insert and update  | 
		
| Список | pgsql-bugs | 
havasvolgyi.otto@gmail.com writes:
> The following bug has been logged on the website:
> Bug reference:      6365
> Logged by:          Otto Havasvölgyi
> Email address:      havasvolgyi.otto@gmail.com
> PostgreSQL version: 9.1.2
> Operating system:   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).  This will cause
the apparent memory consumption of any long-lived backend to increase
until it has touched every available shared buffer.  But that's not a
leak, just an artifact of the reporting tool.  You 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.
            regards, tom lane
		
	В списке pgsql-bugs по дате отправления: