Tom Lane wrote:
> Bruce Momjian 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 eve
Bruce Momjian 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 relu
Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Hmm, are there no other ways that this problem can manifest itself?
> > ISTM that we're relying completely on the kernel to map it in the same
> > place each time. Maybe one day someone changes the startup procedure to
> > allocate some more mem
Martijn van Oosterhout writes:
> Hmm, are there no other ways that this problem can manifest itself?
> ISTM that we're relying completely on the kernel to map it in the same
> place each time. Maybe one day someone changes the startup procedure to
> allocate some more memory and it gets mapped som
On Wed, Feb 01, 2006 at 10:59:39AM -0500, Bruce Momjian wrote:
> * Attach process to shared data structures. If testing
> * EXEC_BACKEND on Linux, you must run this as root
> * before starting the postmaster:
> *
> * echo 0 >/proc/sys/kernel/ran
Added code comment:
/*
* Attach process to shared data structures. If testing
* EXEC_BACKEND on Linux, you must run this as root
* before starting the postmaster:
*
* echo 0 >/proc/sys/kernel/randomize_va_space
*
* T
On Thu, 2006-01-26 at 18:40 -0500, Tom Lane wrote:
> You can work around this by doing (as root)
> echo 0 >/proc/sys/kernel/randomize_va_space
> before starting the postmaster. You'll probably want to set it back to
> 1 when done experimenting with EXEC_BACKEND, since address randomization
>
I just wasted a couple hours trying to determine why an EXEC_BACKEND
build would randomly fail on Fedora Core 4. It seems the reason is that
by default, recent Linux kernels randomize the stack base address ---
not by a lot, but enough to cause child processes to sometimes be unable
to attach to t
