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

Tom Lane <[email protected]>
Newsgroups gmane.comp.db.postgresql.devel.win32
Message-ID <[email protected]>
"Magnus Hagander" <[email protected]> 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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [email protected])
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.