Re: Fwd: 8.0 Beta3 worked, RC1 didn't!

[Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>]

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> Tom,
> why is DC000000 so low? That's still 10Mb into the process, right? Granted, it's not high, but it's not *that* low. (A simple test program with all parameters at default get it's first address allocated at 003D2438 for me. A freshly MapViewOfFile()d memory ends up at 003f0000. If I go for a larger test block (such as 50Mb), the mapped memory is moved up to 004d0000. I get very simlar results on XP and 2003.

The question is not whether it's "low", it's whether there's any
daylight between the end of memory in a postmaster/backend image and
where the shmem segment gets placed.

On Unix, shmat() is supposed to leave a lot of room between the data
break address and where it puts shmem, so that malloc still has room to
play in.  I suspect that Windows is willing to malloc() memory above the
shmem segment and so thinks that it doesn't need to leave any daylight
there, other than rounding off to a page boundary for hardware reasons.
If the backend process malloc's a bit more space than the postmaster did
before trying to attach, we got trouble.

It's not clear to me exactly *why* the backend would allocate any more
space than the postmaster did, but that's my working hypothesis at the
moment.

			regards, tom lane