From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Frank Featherlight <dirtydude(at)gmail(dot)com>, Robert Haas <robertmhaas(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 08:18:37 |
Message-ID: | 49A4FEDD.6080609@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Frank Featherlight <dirtydude(at)gmail(dot)com> writes:
>> while reading your thread two things come to mind, I have installed:
>> Registry Mechanic ( http://www.pctools.com/registry-mechanic )
>> Tune-Up Utilities ( http://www.tune-up.com/products/tuneup-utilities )
>> Any of these two might cause the problem aswell in your opinion?
>
> Damifino, I'm not a Windows person. But I'd suggest methodically
> removing each and every bit of non-default software you've got,
> to see if you can find one that causes the failure. We know that
> the failure does not occur on stock Windows or with most popular
> add-ons, so unusual add-ons deserve a close look.
I wonder if it would help to reserve the address space for the shared
memory block earlier. We could pass the address and size of the shared
memory block as extra arguments to the backend, and reserve it before
doing anything else. There's even a function called VirtualAllocEx, that
postmaster could call right after CreateProcess to reserve the address
space on behalf of the child process.
Of course, none of this helps if the culprit is a DLL or a 3rd party
program that allocates the adress space immediately at CreateProcess.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2009-02-25 09:06:29 | Re: Service not starting: Error 1053 |
Previous Message | Alan Li | 2009-02-25 07:13:30 | Backend assertion failure on \d |