Обсуждение: postgresql-9.0 Windows service stops after database transaction

• Windows XP SP3
• PostgreSQL 9.0.0, compiled by Visual C++ build 1500, 32-bit
• pgAdmin III 1.12.0 (Sep17 2010, rev: REL-1_12_0)
• PostGIS 2.0SVN

Notice:
This email and any attachments may contain information that is personal, confidential,
legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner.

It is the responsibility of the recipient to check for and remove viruses.

If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email.

Please consider the environment before printing this email.

On 24 September 2010 05:39,  <adrian.kitchingman@dse.vic.gov.au> wrote:
> Hi all
>
> I've have a strange problem with my Windows postgresql-9.0 service stopping
> after any transaction which manipulates tables in any database (Deleting
> records, Inserting records, bulk importing via \copy, etc). This problem
> occurs regardless whether I'm accessing the database server via pgAdmin III
> on a client machine or the server itself as well as through the command
> prompt. The end result it that I have to constantly restart the postgresql
> service after any transactions. Sometime there is a slight delay allowing a
> couple of transactions but the service is always eventually stopped.
>
> The problem appears to have started when I changed permissions on my machine
> to allow the user 'postgres' access to the C drive following the
> instructions in the last post of this thread:
> http://www.jitterbit.com/PhpBB/viewtopic.php?f=5&t=869
>
> The specs of postres environment are:
>
> Windows XP SP3
> PostgreSQL 9.0.0, compiled by Visual C++ build 1500, 32-bit
> pgAdmin III 1.12.0 (Sep17 2010, rev: REL-1_12_0)
> PostGIS 2.0SVN
>
> Hope someone can shed some light on this issue.

What appears in the logs?

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

Notice:
This email and any attachments may contain information that is personal, confidential,
legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner.

It is the responsibility of the recipient to check for and remove viruses.

If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email.

Please consider the environment before printing this email.

Notice:
This email and any attachments may contain information that is personal, confidential,
legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner.

It is the responsibility of the recipient to check for and remove viruses.

If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email.

Please consider the environment before printing this email.

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/

Notice:
This email and any attachments may contain information that is personal, confidential,
legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner.

It is the responsibility of the recipient to check for and remove viruses.

If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email.

Please consider the environment before printing this email.