Re: Service not starting: Error 1053

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Frank Featherlight <dirtydude(at)gmail(dot)com>, Richard Huxton <dev(at)archonet(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Service not starting: Error 1053
Date: 2009-02-25 04:38:13
Message-ID: 19427.1235536693@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Frank Featherlight 2009-02-25 04:41:17 Re: Service not starting: Error 1053
Previous Message KaiGai Kohei 2009-02-25 04:15:48 Re: Synchronous replication & Hot standby patches