On 27/09/10 08:06, adrian.kitchingman@xxxxxxxxxxxxxx wrote: > > /2010-09-27 09:53:19 EST LOG: server process (PID 2564) was terminated > by exception 0xC0000005/ > /2010-09-27 09:53:19 EST HINT: See C include file "ntstatus.h" for a > description of the hexadecimal value./ That's an access violation - in UNIX land, a segmentation fault, signal 11. A plain 'ol crash of a backend. It'd be really nice to have some information about how it crashed. It'd be ideal if you could make a .sql file that, when run on a newly created database, creates a table and manipulates it in a way that causes the backend to crash. Please do not add PostGIS to the test database. If you cannot make it crash without PostGIS in the mix, that tells us something. If you can make it crash without PostGIS, please post the .sql file that creates the table(s) and runs the command that crashes the server. If you have to add PostGIS to make it crash, it might be best to talk to the PostGIS folks about the problem. In either case, to make things even better you could collect some crash information that may help diagnose where in PostgreSQL the crash occurs. See: http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows By the way: You don't have the old 8.3 data directory on the system PATH do you? You can check the value of the system path in the System control panel, though exactly where varies from Windows version to Windows version. -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/ -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
