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
of:
* 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:
http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
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
directory.
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
use.
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
instead.
--
Craig Ringer
