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

> >> 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.
>
>
> Still unable to reproduce this, even with the more detailed
> steps in Nicolas mail. However, I've created a postgres.exe
> based on cvs-as-of-yesterday plus the attached patch for testing.
>
> The file is available on
> http://www.hagander.net/pgsql/postgres_shmem.zip
>
>
> Nicolas and Merlin - can you test with this .exe, please? You
> need to replace *both* postmaster.exe *and* postgres.exe with
> the new one.

I've now had confirmation from one person (Edgars) that this solves his
problem. I'd like confirmation from at least one more, but things point
towards this being the reason.

Tom - what's next? Do we want to roll RC3 with this ugly fix, or do we
want to look at a better fix right away?

One thought - what if we hard-code the address to somewhere at the 1Gb
limit? That would limit us to 1Gb of shared buffers (or 2Gb if started
witht he /3G switch to give user programs 3Gb in windows), but I don't
see *anybody* needing 1Gb shared buffers... Or is that a bad idea?

//Magnus