Re: HEADS UP: Win32/OS2/BeOS native ports

Jason Tishler wrote:
>
> 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).

I'm not sure the DLL load address is a big issue for PostgreSQL, AFAIK no
option DLLs will be loaded by Postmaster. So, with fork() it will be a simple
process. A PostgreSQL child will die upon completion, and never execute fork().

My concern would be the limit on the number of child processes allowed. 63 is
far below what would be considered a usable number in production, and as long
as that is an issue, I don't think anyone would take PostgreSQL seriously.

A Windows version of PostgreSQL must run within the confines of the Windows OS.
The reason, IMHO, that no one has found any serious bugs in the cygwin version,
is because no one is seriously using it. Anyone who *would* seriously use it,
knows better.