Re: OK, lets talk portability. - Mailing list pgsql-hackers

From Dann Corbit
Subject Re: OK, lets talk portability.
Date
Msg-id D90A5A6C612A39408103E6ECDD77B82906F43D@voyager.corporate.connx.com
Whole thread Raw
In response to OK, lets talk portability.  (mlw <markw@mohawksoft.com>)
List pgsql-hackers
> -----Original Message-----
> From: mlw [mailto:markw@mohawksoft.com]
> Sent: Tuesday, May 07, 2002 7:44 AM
> To: Tom Lane
> Cc: Marc G. Fournier; PostgreSQL-development
> Subject: Re: [HACKERS] OK, lets talk portability.
>
>
> Tom Lane wrote:
> > And no, I don't want to undo those changes.  Especially not if the
> > only reason for it is to not have to use Cygwin on Windows.  Most
> > of these changes made the startup code substantially simpler,
> > faster, and more reliable.
>
> Then I think the notion of a pure Windows version is dead in
> the water. Writing
> a fork()-like API for Windows is, of course, doable as
> evidenced by cygwin, and
> from a general theory seems like a pretty straight forward
> thing to do (with a
> few low level tricks of course) but the details are pretty scary.
>
> Has anyone done a profile of PostgreSQL running on a windows
> box and identified
> cygwin bottlenecks which we could augment with native code?

PW32:
http://pw32.sourceforge.net/
has a better fork than Cygwin(), but it is still awful.  Much better to
start a new server with CreateProcess() on Win32 [absurdly faster].

The idea of fork() translation is to copy the heap and auto data.  But
the heap can split, so it isn't even really guaranteed to work.
Quite frankly, fork() in Win32 is a very, very bad idea.  Not just for
efficiency reasons but also for reliability reasons.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Set Returning Functions (SRF) - request for patch review and comment
Next
From: mlw
Date:
Subject: Re: OK, lets talk portability.