Hi, Tom,
One more question. I'm new to PostgreSQL and not an expert in debugging. After
checking the manual, I think I need to turn on the following parameters in
order to generate debug info. Do you think doing so would give us what we need
to pinpoint the problem?
debug_assertions
trace_notify
trace_sort
debug_print_parse
debug_print_rewritten
debug_print_plan
debug_pretty_print
Thanks.
--- On Tue 07/10, Tom Lane < [EMAIL PROTECTED] > wrote:
From: Tom Lane [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-general@postgresql.org
Date: Tue, 10 Jul 2007 20:04:41 -0400
Subject: Re: [GENERAL] exit code -1073741819
"Shuo Liu" <[EMAIL PROTECTED]> writes:> The log shows the following message:>
CurTransactionContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used>
ExecutorState: 122880 total in 4 blocks; 1912 free (9 chunks); 120968 used>
ExprContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used>
ExprContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used>
ExprContext: 8192 total in 1 blocks; 8000 free (1 chunks); 192 used>
ExprContext: 8192 total in 1 blocks; 8000 free (1 chunks); 192 used>
ExprContext: 8192 total in 1 blocks; 8096 free (1 chunks); 96 used> SPI Exec: 0
total in 0 blocks; 0 free (0 chunks); 0 used> SPI Proc: 8192 total in 1 blocks;
2616 free (0 chunks); 5576 used> ExecutorState: 57344 total in 3 blocks; 35776
free (7 chunks); 21568 used> ExprContext: 0 total in 0 blocks; 0 free (0
chunks); 0 usedThe above is a fragment of a memory stats dump, which normally
wouldonly be emitted if you had an out-of-memory situation. However thepart of
it that you've shown
doesn't indicate any particularly heavymemory usage. Were there any large
numbers in the preceding similarly-formatted lines? Was there anything
possibly relevant in the logentries before that?> 2007-07-10 12:25:57 LOG:
server process (PID 2004) exited with exit code -1073741819I suppose you're on
Windows? This is what is currently printed for anAccess Violation trap on
Windows. The fact that it came out partwaythrough a stats dump is pretty
suspicious; it suggests that the traphappened as a result of trying to scan the
memory context bookkeepingdata, which implies a memory clobber of some sort.So
you're looking at a bug, but there's much too little data here toguess what the
bug is. Can you get a debugger stack trace? Or puttogether a self-contained
test case for someone else to poke at?Actually the *first* thing to do is make
sure you are up to date onboth Postgres and PostGIS versions. No sense in
spending a lot of timechasing down a bug if it's already been fixed.
regards, tom lane
_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
