Re: FATAL: could not reattach to shared memory (Win32) - Mailing list pgsql-general

From Tom Lane
Subject Re: FATAL: could not reattach to shared memory (Win32)
Date
Msg-id 1225.1187970372@sss.pgh.pa.us
Whole thread Raw
In response to Re: FATAL: could not reattach to shared memory (Win32)  ("Trevor Talbot" <quension@gmail.com>)
Responses Re: FATAL: could not reattach to shared memory (Win32)  (Terry Yapt <yapt@technovell.com>)
List pgsql-general
"Trevor Talbot" <quension@gmail.com> writes:
> On 8/23/07, Magnus Hagander <magnus@hagander.net> wrote:
>> Not that wild a guess, really :-) I'd say it's a very good possibility -
>> but I have no idea why it'd do that, since all backends load the same
>> DLLs at that stage.

> Not a valid assumption; you can't rely on consistent VM space among
> multiple [non-cloned] processes without a serious amount of effort.

I'm not sure if you have a specific technical meaning of "clone" in mind
here, but these processes are all executing the identical executable,
and taking care to map the shmem early in execution *before* they load
any DLLs.  So it should work.  Apparently, it *does* work for awhile for
the OP, and then stops working, which is even odder.

> I gather postgres depends on it being at the same address, and fixing
> that isn't trivial?

That's correct, and not having to change it is not negotiable ---
finding a way to make this work was one of the gating factors that
made it practical to have a Windows port at all.

If you've got a specific suggestion for making it more reliable,
we're all ears.

            regards, tom lane

pgsql-general by date:

Previous
From: Lee Keel
Date:
Subject: Re: [OT - sorta] How to extract a substring using Regex
Next
From: Erik Jones
Date:
Subject: Re: Out of Memory - 8.2.4