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,merlin(dot)moncure(at)rcsonline(dot)com
Subject: Re: Fwd: 8.0 Beta3 worked, RC1 didn't!
Date: 2004-12-28 16:27:01
Message-ID: 200412281627.iBSGR3v02251@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > 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?
> 
> That was suggested already.  As a permanent fix it's certainly
> unspeakably ugly, but it would be useful to try it just to prove
> (or disprove) that we understand the problem.
> 
> It would probably be a good idea to make the padding at least 256K,
> since the numbers that have been tossed around seem to indicate that
> Windows may be aligning things on 128K boundaries.
> 
> My inclination for a permanent fix would be to try to do the shmat()
> much earlier, but I don't think we should go to the effort of doing
> that code rearrangement until we've proven that this is indeed the
> issue.

Right.  Merlin, I added you to this email.  Can you test that?  Do you
need us to send you a patch for testing?

-- 
  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

pgsql-hackers-win32 by date

Next:From: Magnus HaganderDate: 2004-12-28 18:26:08
Subject: Re: Fwd: 8.0 Beta3 worked, RC1 didn't!
Previous:From: Tom LaneDate: 2004-12-28 16:19:50
Subject: Re: Fwd: 8.0 Beta3 worked, RC1 didn't!

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