On Mon, Jun 03, 2002 at 09:36:51AM -0400, mlw wrote:
> Jason Tishler wrote:
> >
> > On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote:
> > > Bruce Momjian wrote:
> > > > mlw wrote:
> > > > > Like I told Marc, I don't care. You spec out what you want and I'll
> > > > > write it for Windows.
> > > > >
> > > > > That being said, a SysV IPC interface for native Windows would be
> > > > > kind of cool to have.
> > > >
> > > > I am wondering why we don't just use the Cygwin shm/sem code in our
> > > > project, or maybe the Apache stuff; why bother reinventing the wheel.
> > >
> > > but! in the course of testing some code, I managed to gain some experience
> > > with cygwin. I have seen fork() problems with a large number of processes.
> >
> > Since Cygwin's fork() is implemented with WaitForMultipleObjects(),
> > it has a limitation of only 63 children per parent. Also, there can
> > be DLL base address conflicts (causing Cygwin fork() to fail) that are
> > avoidable by rebasing the appropriate DLLs. AFAICT, Cygwin PostgreSQL is
> > currently *not* affected by this issue where as other Cygwin applications
> > such as Python and Apache are.
>
> Why would not PostgreSQL be affected by this?
Sorry, if I was unclear -- I should have used two paragraphs above and
maybe a few more words... :,)
Cygwin PostgreSQL *is* affected by the Cygwin 63 children per parent
fork limitation.
PostgreSQL *can* be affected by the Cygwin DLL base address conflict
fork issue, but in my experience (both personal and by monitoring the
Cygwin and pgsql-cygwin lists), no one has been affected yet. The DLL
base address conflict is a "probability" thing. The more DLLs loaded
the greater the chance of a conflict (and fork() failing). Since, Cygwin
PostgreSQL loads only a few DLLs, this has not become an issue (yet).
Jason
