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/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
