Re: HEADS UP: Win32/OS2/BeOS native ports
От | Marc G. Fournier |
---|---|
Тема | Re: HEADS UP: Win32/OS2/BeOS native ports |
Дата | |
Msg-id | 20020503113420.C97878-100000@mail1.hub.org обсуждение исходный текст |
Ответ на | Re: HEADS UP: Win32/OS2/BeOS native ports (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: HEADS UP: Win32/OS2/BeOS native ports
|
Список | pgsql-hackers |
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 ...
В списке pgsql-hackers по дате отправления: