Skip site navigation (1) Skip section navigation (2)

Re: A note about testing EXEC_BACKEND on recent Linuxen

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: A note about testing EXEC_BACKEND on recent Linuxen
Date: 2006-02-01 19:50:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to


pgsql-hackers by date

Next:From: Chris BrowneDate: 2006-02-01 19:51:36
Subject: Re: autovacuum
Previous:From: Bruce MomjianDate: 2006-02-01 19:39:30
Subject: Re: A note about testing EXEC_BACKEND on recent Linuxen

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