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

Gary Doades <gpd@gpdnet.co.uk> writes:
> Tom Lane wrote:
>> Win32 may not care, but we do.  The shared memory segment must be mapped
>> at the same address in every backend.

> Forgive me for not knowing the internals of postgres, but why? As long
> as all the shared memory is accessed from the same relative offsets from
> the private starting address it will refer to the same physical shared
> memory address and should work.

Because we use absolute addresses in many cases.  There was once a
convention of making everything relative to ShmemBase, but we've
abandoned that for reasons of code simplicity (and to a lesser extent
performance).  There are still some places using relative offsets but
they are gradually going away.  We are not reversing that decision
just because some flavors of Windows have stupid algorithms for
assigning default shmem addresses.

> If this is the case then your suggestion may be the only one, to
> artificially bump up the first free address and hope that it is enough.
> Seems a bit hit and miss though (probably more hit than miss) since it's
> not easily known what the extra allocation for the subsequent backends
> may be.

The needed extra allocation should really be *zero*.  Keep in mind that
the intention of the EXEC_BACKEND code is to emulate the Unix case where
backends are spawned by fork().  Therefore the state of the backend at
the point where it needs to attach to shmem should really be hardly at
all different from the state of the postmaster.  I'm moderately
interested to find out why changing listen_addresses seems to affect
this, but on the strength of the available evidence I'd suspect it's a
matter of just a few bytes that happens to exceed an allocation
boundary.

It might be that we could solve the problem by rethinking the order of
operations --- maybe we should reattach to shared memory during
restore_backend_variables, before the exec'd backend has had a chance to
do much of anything.

            regards, tom lane