On 8/23/07, Magnus Hagander <magnus@hagander.net> wrote:
> Shelby Cain wrote:
> > Wild guess on my part... could that error be the result of an attempt
> > to map shared memory into a process at a fixed location that just
> > happens to already be occupied by a dll that Windows had decided to
> > relocate?
>
> 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.
Anything can use that space, it's not just file views. Obviously it
happens to work some of the time, but when it doesn't, it doesn't. I
gather postgres depends on it being at the same address, and fixing
that isn't trivial?
If everything relevant is going through the intriguing
internal_forkexec(), you could probably reserve address space there
before resuming the thread. You'd want to combine this with picking
address space that's less likely to be used before creating the shared
memory section. (Actually, if you're doing that, you might as well
just inject the backend variables too instead of going through the
mapped file gymnastics.)
Not a simple change, but would likely make this particular problem go
away (assuming this is the problem). It's also the first time I've
looked at the source, so perhaps I missed something.
