On 05/06/10 01:02, Rob Richardson wrote:
> We have a customer who is running PostgreSQL 8.4 on a Windows Server
> 2003 box. The Postgres service is set up to store data on the
> computer's H drive, which is actually an iSCSI connection to a folder of
> a disk drive on a separate computer. The same computer that runs
> PostgreSQL also runs the Kepware OPC server. If a user needs to connect
> remotely to this computer to change something in the OPC server, he has
> to connect using "mstsc /admin". More often than not, when a user
> connects remotely using the /admin option, PostgreSQL will crash. The
> only indication of a problem left in the log file is a message saying
> that error 128 happened, which is a problem with a child process. It
> does not say which process, or what the problem was.
>
> The only reference we were able to find on the Web for this problem said
> that it went away when the user upgraded from 8.3.1 to 8.4. That was
> why we did the same upgrade. For us, the problem still exists.
Since you have a fairly reliable way to reproduce the crash, a backtrace
showing what is actually happening might be really handy. See:
http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
--
Craig Ringer
Tech-related writing: http://soapyfrogs.blogspot.com/