On Fri, 3 May 2002, Tom Lane wrote:
> "Marc G. Fournier" <scrappy@hub.org> writes:
> > The initial changes will be to just wrapper all our shared memory
> > code, so that I can make use of Apache's libapr libraries *if* they are
> > installed ... if not, it will just fall back to "the current code" ...
>
> I think we should redesign the shared memory API (and even more so the
> semaphore API), not just put a wrapper layer on it. A lot of the
> internal API is unnecessarily dependent on SysV shmem/sem behavior.
>
> Note however that there are some things you will break if you are not
> very careful. We are depending on shmem/sem behavior to catch a number
> of multiple-postmaster conflict situations. If there's not a more or
> less SysV-ish kernel underneath us, those situations will have to be
> rethought and some other interlock invented.
>
> In short, I want to see a design review first, not a bunch of
> off-the-cuff commits.
All I'm planning on doing is changing the appropriate shm_* functions iwth
pg_shm_* functions ... if !(libapr), all those pg_shm_* functions will
have in them is the original call we've always used ... there will even be
a --disable-libapr configure option so that if someone already has Apache2
installed, but doesn't wanna use libapr for PgSQL, they don't have to ...
Basically, all I'm looking at is allowing PgSQL to use a different library
for its shared memory calls then the standard one, nothing else ...