Re: A note about testing EXEC_BACKEND on recent Linuxen - Mailing list pgsql-hackers

From Tom Lane
Subject Re: A note about testing EXEC_BACKEND on recent Linuxen
Date
Msg-id 3904.1138823443@sss.pgh.pa.us
Whole thread Raw
In response to Re: A note about testing EXEC_BACKEND on recent Linuxen  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: A note about testing EXEC_BACKEND on recent Linuxen
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> FYI, the shared memory address was originally relocatable by using
> offsets to address it from the child, but now that we use fork() on
> Unix, it isn't an issue, and Win32 seems to be OK.

In the worst case we could go back to using offsets everywhere, but I'm
really reluctant to do that for reasons of code clarity and reliability.
The main problem with it is that you have to explicitly cast to and from
the correct pointer type, which is not only ugly but completely defeats
any chance of the compiler catching wrong-type errors.

What I am seeing on Fedora 4 (I suppose it's common to most recent Linux
versions) is that the system preferentially maps the shared memory
segment just below the stack, which is good from the point of view of
preserving maximum address space for the heap, but not so great if stack
size changes or the stack moves a bit.  It'd be possible to get a little
more flexibility by requesting a non-default attach location for the
postmaster's initial shmat call.  I'm not interested in getting into
that if we don't absolutely have to, but it might be the best answer if
we find ourselves seeing similar issues on specific platforms (ie
Windows) in the future.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: A note about testing EXEC_BACKEND on recent Linuxen
Next
From: Chris Browne
Date:
Subject: Re: autovacuum