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.
>
> Has anyone else seen and fixed this problem?
I've been watching these various reports of MSTSC causing the postgres
service process to crash, and must say I've very mystified as to what
possible mechanisms could be involved. I should note, I almost
exclusively run postgres on Unix (AIX, Solaris) and Linux (mostly
RHEL/CentOS), but I am quite familiar with MS Windows Server innards
from other contexts.
I do hope your description of the iscsi connection is somewhat vague and
mildly incorrect. ISCSI targets (servers) are block devices, and
usually serve either a disk partition or a single large file up as the
logical unit to the iscsi initiator (your win2003 postgres server in
this context). also, I would ONLY run a database across iscsi if the
iscsi target/server is a really robust appliance kind of environment,
and not some sort of adhoc "oh look, we have some spare space over here,
lets just serve it up", as if you reboot that target machine, the
initiator (client) is gonna throw a hissy fit.
The one thing that MSTSC /ADMIN does that might impact processes is
notify all processes in the 'desktop session' that the display driver
and resolution etc is changing, I believe via a WM_DISPLAYCHANGE. I
can't see how this could impact a background service process, but if its
service wrapper didn't handle this message well, perhaps thats a clue?
Does the 'new' version of Postgres for Windows packaged by EnterpriseDB
have any sort of notify tray icon?
