Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I don't really know anything about PostgreSQL on Windows, so I'm
> afraid I can't give you too much help. My gut feeling from years of
> experience with debugging random weird problems on various platforms
> is that we need to know more about why this is happening to you and
> not to other people.
It is happening to *some* other people, as shown by previous bug
reports, but what we lack is a way to reproduce it or identify just
what's causing it.
The error number 487 (which I think Frank is the first reporter to
positively confirm) confirms our previous theory that the problem is
inability to map the shared memory segment due to something else having
already occupied the needed address range in the new child process.
However, since the child process is running the same postmaster
executable that was able to map the shared memory segment at that
address to begin with, it's far from clear why that failure should
occur. And experience shows that most of the time, for most people,
it doesn't occur.
My guess is that the cause is some sort of add-on software that
invasively attaches itself to new processes. That could well be
an antivirus, or a virus, or something else entirely (network
stack addon?). Your suggestions about methodically trying to
identify the cause are good.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Frank Featherlight||Date: 2009-02-25 04:41:17|
|Subject: Re: Service not starting: Error 1053|
|Previous:||From: KaiGai Kohei||Date: 2009-02-25 04:15:48|
|Subject: Re: Synchronous replication & Hot standby patches|