Skip site navigation (1) Skip section navigation (2)

Re: BUG #4996: postgres.exe memory consumption keeps going up

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: "WANGRUNGVICHAISRI, SHIVESH" <sbw(at)appsig(dot)com>
Cc: pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #4996: postgres.exe memory consumption keeps going up
Date: 2009-08-26 15:38:17
Message-ID: 1251301097.26678.34.camel@ayaki (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
On Wed, 2009-08-26 at 07:09 -0700, WANGRUNGVICHAISRI, SHIVESH wrote:

> I also did use the Process Explorer as you suggested; I'm sorry I
> didnt mention that in the post. As I mentioned before in the zip file,
> the working set kept growing.

Yes, but does the *private* working set? The screen shots of the Task
Manager you supplied suggest it does not. Please provide screen
recordings, screenshots, or other details from Process Explorer that
show the growing private working set. You're just not providing the
details needed to understand this, which are AT LEAST timed snapshots

* For both active postgres.exe backends and SandboxTest.exe:
** Total working set size
** Private working set size
** Shared memory size
** Sharable memory size

Process Explorer can tell you all these.

If it is in fact postgres.exe that crashes at some point, it'd also
*REALLY* help to have a backtrace of the crash. Please see this wiki
article on how to collect a backtrace of a crashing process:

This is REALLY important to help identify where the memory being
allocated is. Note that you will need to set up your debug environment
as per the instructions and make sure the stack trace is a useful one.

> I will keep the program running today until it crashes.

I've now been able to get your test program to crash (but not
postgres.exe - only SandboxTest.exe). The postgres.exe backends are fine
and do not have any problems. I'm running your test program again with a
debugger attached.

>  Which one is the postgresql log file that you would be interested in
> looking at?

The most recent log in the pg_log directory inside the postgresql data

Please confirm the crash USING SANDBOXTEST.EXE not the real application.
You need to be using the same test program as I am for it to be much

If you cannot cause the postgres.exe crash with sandboxtest.exe but you
can with your real application, then the test case isn't actually
demonstrating the problem and we'll need different debugging tactics

Craig Ringer

In response to


pgsql-hackers by date

Next:From: Michael GlaesemannDate: 2009-08-26 15:44:11
Subject: Re: 8.5 release timetable, again
Previous:From: Andrew DunstanDate: 2009-08-26 15:37:10
Subject: Re: 8.5 release timetable, again

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-08-26 15:40:04
Subject: Re: BUG #5011: Standby recovery unable to follow timeline change
Previous:From: Heikki LinnakangasDate: 2009-08-26 15:36:46
Subject: Re: BUG #5011: Standby recovery unable to follow timeline change

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group