On 27/09/10 08:06, adrian.kitchingman@dse.vic.gov.au 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/