"Shuo Liu" <delphet@xxxxxxxxxx> 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 used The above is a fragment of a memory stats dump, which normally would only be emitted if you had an out-of-memory situation. However the part of it that you've shown doesn't indicate any particularly heavy memory usage. Were there any large numbers in the preceding similarly- formatted lines? Was there anything possibly relevant in the log entries before that? > 2007-07-10 12:25:57 LOG: server process (PID 2004) exited with exit code -1073741819 I suppose you're on Windows? This is what is currently printed for an Access Violation trap on Windows. The fact that it came out partway through a stats dump is pretty suspicious; it suggests that the trap happened as a result of trying to scan the memory context bookkeeping data, which implies a memory clobber of some sort. So you're looking at a bug, but there's much too little data here to guess what the bug is. Can you get a debugger stack trace? Or put together 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 on both Postgres and PostGIS versions. No sense in spending a lot of time chasing down a bug if it's already been fixed. regards, tom lane
