Hi, Tom, Thanks for the reply. I'll try to provide as much information as I can. > 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 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? The lines that start with "ExecutorState" have similar big numbers and numbers in other lines are smaller. >Was there anything possibly relevant in the logentries before that? Logentries right after normal script output are listed below (those are just the ones on the top and the rest are similar): TopMemoryContext: 11550912 total in 1377 blocks; 123560 free (833 chunks); 11427352 used SPI Plan: 3072 total in 2 blocks; 888 free (0 chunks); 2184 used SPI Plan: 7168 total in 3 blocks; 3368 free (0 chunks); 3800 used SPI Plan: 1024 total in 1 blocks; 256 free (0 chunks); 768 used > 2007-07-10 12:25:57 LOG: server process (PID 2004) exited with exit code -1073741819I suppose you're on Windows? Yes, it is Windows XP SP2. Sorry that I didn't mention it before. >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 toguess 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? The spatial database that the script is using is quite large (about 4 GB). So I think making a self-contained test case would be the last resort. I'll reset some parameters and try to generat debug info. I'll post it here as soon as it is available. >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 timechasing down a bug if it's already been fixed. The version of PostgreSQL is 8.2.4. PostGIS is 1.2.1 that is for PostgreSQL 8.2.4. So I think the installation is up to date. _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web!
