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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
