Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>,pgsql-hackers-win32(at)postgresql(dot)org, nico(at)def2shoot(dot)com
Subject: Re: Fwd: 8.0 Beta3 worked, RC1 didn't!
Date: 2004-12-28 16:15:50
Message-ID: 200412281615.iBSGFox00142@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
Tom Lane wrote:
> "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.

What if we malloc 100k just before we create the postmaster segment and
then free it and see if that fixes the postgres.exe problem?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-hackers-win32 by date

Next:From: Tom LaneDate: 2004-12-28 16:19:50
Subject: Re: Fwd: 8.0 Beta3 worked, RC1 didn't!
Previous:From: Tom LaneDate: 2004-12-28 16:01:27
Subject: Re: Fwd: 8.0 Beta3 worked, RC1 didn't!

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group