From: | "Marc G(dot) Fournier" <scrappy(at)hub(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: HEADS UP: Win32/OS2/BeOS native ports |
Date: | 2002-05-03 14:54:27 |
Message-ID: | 20020503114846.U97878-100000@mail1.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 3 May 2002, Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> > 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 ...
>
> Oh. I guess my next question is how closely that Apache library
> emulates the SysV shmem semantics. In particular, can you reliably
> tell how many processes are attached to a shmem block? (Cf
> SharedMemoryIsInUse() in storage/ipc/ipc.c) Without that feature we
> have an interlock problem.
Will investigate this ... my immediate goal is to just get it so that an
alternate library can be used ... default behaviour will be to stick with
our current function calls ... to use libapr, you will/would have to use a
configure option for it (sorry, meant --enable above, not --disable) ...
The only '#ifdef's I'm planning on for this will be in a central shmem.*
file(s), so there isn't going to be a string of those all over the place
or anything stupid like that ...
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2002-05-03 15:02:25 | Re: HEADS UP: Win32/OS2/BeOS native ports |
Previous Message | Tom Lane | 2002-05-03 14:44:34 | Re: Schemas: status report, call for developers |