Tom Lane wrote:
> Forwarding the attached in case anyone missed it on -general.
>
> The shmem attach address shown in his messages (00DC0000) seems mighty
> low. What I am suspecting is:
> 1. Postmaster boots, creates shmem, and for some idiotic reason
> 2003 Server creates the shmem segment just above the end of
> regular memory.
> 2. When subprocesses launch and re-read GUC settings, for one
> reason or another they use up a little more RAM than the
> postmaster did.
> 3. Subprocesses fail to attach to shmem because the target
> address is now in their regular RAM range.
>
> I don't know why 2003 Server has such a brain-dead choice of shmem
> address assignment, nor why listen_addresses might prompt a little extra
> growth of RAM usage. But the theory seems to fit the available facts.
>
> If this is correct then we have to do something to force a smarter
> choice of shmem address on Windows. One brute-force way to do it
> might be to malloc a couple hundred K just before the postmaster
> attaches to shmem, and then release?
>
> Theory B is that somehow UsedShmemSegAddr is not being passed down
> accurately in this case, but that seems a mite improbable.
I am confused. I thought we used a hard-coded location for shared
memory on Win32.
I thought it was 00xDB0000 something but I can't find any mention of
that. Was it removed? Are we now starting the postgres.exe binary and
assuming we can map to the same shared memory address as postmaster.exe?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073