Re: OK, lets talk portability.

From: "Dann Corbit" <DCorbit(at)connx(dot)com>
To: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: OK, lets talk portability.
Date: 2002-05-07 18:02:46
Message-ID: D90A5A6C612A39408103E6ECDD77B82906F43D@voyager.corporate.connx.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: mlw [mailto:markw(at)mohawksoft(dot)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.

Browse pgsql-hackers by date

  From Date Subject
Next Message Dann Corbit 2002-05-07 18:26:17 Re: OK, lets talk portability.
Previous Message Marc G. Fournier 2002-05-07 17:52:26 Re: How much work is a native Windows application?