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

From Bruce Momjian
Subject Re: A note about testing EXEC_BACKEND on recent Linuxen
Date
Msg-id 200602012014.k11KErH26684@candle.pha.pa.us
Whole thread Raw
In response to Re: A note about testing EXEC_BACKEND on recent Linuxen  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> 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.

As I remember, the offsets also had a performance and/or storage impact
we don't want either.

> 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.

Agreed.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Chris Browne
Date:
Subject: Re: autovacuum
Next
From: Hannu Krosing
Date:
Subject: Question about ALTER TABLE SET TABLESPACE locing behaviour