Thread: How much work is a native Windows application?

I mentioned in another thread, Windows does not support "fork()."  PostgreSQL
seems irrevocably tied to using fork(). Without a drastic rewrite of how
postmaster works, I don't see a way to make a pure Windows version.

The big trick to cygwin is its implementation of fork(). It represents a very
important and fairly mature technique. It can be written for PostgreSQL but it
would require a fair amount of development time and testing.

Then we would need to be able to trace all the native API calls made so that
things like file handles are dealt with correctly for the child process.

I see cygwin as a portability layer or subsystem, as such, it should be able to
emulate foreign operating system constructs. A native application should, on
the other hand, not attempt to do so.

There is a strategy PostgreSQL could use:

Put all global variables which need to be duplicated in a single place, perhaps
a struct, which can be copied into the child process. On systems without
fork(), the memory can be duplicated or passed around using a shared memory
block, on a system with fork(), nothing extra would need to be done. This could
be implemented using "standard" APIs, with little or no specialized OS
knowledge. 

This represents a lot of reworking of code, but should not affect much in the
way of operation, but would require a lot of typing and testing. It would also
force restrictions on module static and global variables.

I will sign up to do the Windows stuff to get this to work, but it will take a
lot of postgres internal reworking that I am not up for doing.

The other alternative, is to profile PostgreSQL running in the cygwin
environment and try to assess where any bottlenecks are, and if there are any
spot optimizations which can be applied.

http://www.mkssoftware.com/docs/man3/fork.3.asp

http://www.computing.net/programming/wwwboard/forum/60.html

http://www.research.att.com/sw/tools/uwin (Semaphores & Fork)

On Tue, 7 May 2002, mlw wrote:

> I mentioned in another thread, Windows does not support "fork()."  PostgreSQL
> seems irrevocably tied to using fork(). Without a drastic rewrite of how
> postmaster works, I don't see a way to make a pure Windows version.
>
> The big trick to cygwin is its implementation of fork(). It represents a very
> important and fairly mature technique. It can be written for PostgreSQL but it
> would require a fair amount of development time and testing.
>
> Then we would need to be able to trace all the native API calls made so that
> things like file handles are dealt with correctly for the child process.
>
> I see cygwin as a portability layer or subsystem, as such, it should be able to
> emulate foreign operating system constructs. A native application should, on
> the other hand, not attempt to do so.
>
> There is a strategy PostgreSQL could use:
>
> Put all global variables which need to be duplicated in a single place, perhaps
> a struct, which can be copied into the child process. On systems without
> fork(), the memory can be duplicated or passed around using a shared memory
> block, on a system with fork(), nothing extra would need to be done. This could
> be implemented using "standard" APIs, with little or no specialized OS
> knowledge.
>
> This represents a lot of reworking of code, but should not affect much in the
> way of operation, but would require a lot of typing and testing. It would also
> force restrictions on module static and global variables.
>
> I will sign up to do the Windows stuff to get this to work, but it will take a
> lot of postgres internal reworking that I am not up for doing.
>
> The other alternative, is to profile PostgreSQL running in the cygwin
> environment and try to assess where any bottlenecks are, and if there are any
> spot optimizations which can be applied.
>

mlw <markw@mohawksoft.com> writes:
> There is a strategy PostgreSQL could use:

> Put all global variables which need to be duplicated in a single
> place, perhaps a struct, which can be copied into the child
> process. On systems without fork(), the memory can be duplicated or
> passed around using a shared memory block, on a system with fork(),
> nothing extra would need to be done. This could be implemented using
> "standard" APIs, with little or no specialized OS knowledge.

> This represents a lot of reworking of code, but should not affect much
> in the way of operation, but would require a lot of typing and
> testing. It would also force restrictions on module static and global
> variables.

Yeah.  The real problem with it in my eyes is that it'd be a continuing
maintenance headache: straightforward programming techniques that work
fine on all the Unix ports would fail (perhaps in nonobvious ways) when
moved to Windows, should you forget to put a variable in the right
place.

A lesser objection is that variables that can currently be "static" in
a single module would become exposed to the world, which again is a
maintenance problem.

> The other alternative, is to profile PostgreSQL running in the cygwin
> environment and try to assess where any bottlenecks are, and if there
> are any spot optimizations which can be applied.

It'd be worth trying to understand cygwin issues in detail before we
sign up to do and support a native Windows port.  I understand the
user-friendliness objection to cygwin (though one would think proper
packaging might largely hide cygwin from naive Windows users).  What
I don't understand is whether there are any serious performance lossages
from it, and if so whether we could work around them.
        regards, tom lane

"Marc G. Fournier" wrote:
> 
> http://www.mkssoftware.com/docs/man3/fork.3.asp
> 
> http://www.computing.net/programming/wwwboard/forum/60.html
> 
> http://www.research.att.com/sw/tools/uwin (Semaphores & Fork)

These are pretty much what I have been saying. 

Is PostgreSQL going to implement its own fork()? If so, what's the point? Just
use cygwin.

Without trying to sound conceited, I can write a fork() call, that's not the
problem. How much time will it take to do and get right? What about all the
infrastructure? Tracking file handles and resources allocated so that they can
be properly duplicated for the child process, etc. It is a lot of work, and to
do it for a BSD license, I shouldn't reference the cygwin code to do so.

The semaphore, shared memory, file API, etc. all these are straight forward.
They can be handled with a set of macros and some thin functions.

The problems of a native PostgreSQL on Windows is fork(), and all the
subtleties that go with it like ownership of system resources allocated by the
parent and passed to the child and initialization of global and static
variables.

Adding fork() to postgres seems silly. Cygwin does it already, and it seems
like it is outside the scope of what should be supported by PostgreSQL.

Since RedHat owns cygwin and they want RedHat database to be a success, maybe
they can make an exception to the GNU license for PostgreSQL. 

Does anyone think it is a good idea for PostgreSQL to implement it's own
version of fork()?

On Tue, 7 May 2002, Tom Lane wrote:

> It'd be worth trying to understand cygwin issues in detail before we
> sign up to do and support a native Windows port.  I understand the
> user-friendliness objection to cygwin (though one would think proper
> packaging might largely hide cygwin from naive Windows users).  What I
> don't understand is whether there are any serious performance lossages
> from it, and if so whether we could work around them.

Actually, there are licensing issues involved ... we could never put a
'windows binary' up for anon-ftp, since to distribute it would require the
cygwin.dll to be distributed, and to do that, there is a licensing cost
... of course, I guess we could require ppl to download cygwin seperately,
install that, then install the binary over top of that ...

"Marc G. Fournier" <scrappy@hub.org> writes:
> On Tue, 7 May 2002, Tom Lane wrote:
>> It'd be worth trying to understand cygwin issues in detail before we
>> sign up to do and support a native Windows port.

> Actually, there are licensing issues involved ... we could never put a
> 'windows binary' up for anon-ftp, since to distribute it would require the
> cygwin.dll to be distributed, and to do that, there is a licensing cost
> ... of course, I guess we could require ppl to download cygwin seperately,
> install that, then install the binary over top of that ...

<<itch>>  And how much development time are we supposed to expend to
avoid that?

Give me a technical case for avoiding Cygwin, and maybe I can get
excited about it.  I'm not planning to lift a finger on the basis
of licensing though... after all, Windows users are accustomed to
paying for software, no?
        regards, tom lane

...
> Give me a technical case for avoiding Cygwin, and maybe I can get
> excited about it.  I'm not planning to lift a finger on the basis
> of licensing though... after all, Windows users are accustomed to
> paying for software, no?

<evil grin>

You tell us: RH sells our database and sells cygwin, so might have an
opinion on the subject. Perhaps they would like to contribute back some
no cost package licensing terms for cygwin if used for PostgreSQL?? ;)
                   - Thomas

Le Mardi 7 Mai 2002 20:32, mlw a écrit :
> Since RedHat owns cygwin and they want RedHat database to be a success,
> maybe they can make an exception to the GNU license for PostgreSQL.

Cygwin received contributions from several authors. To leave a GNU licence,
you need to get the agreement of all authors, which is not possible for a big
project like Cygwin.

Alternatively, you could pick-up the old static version of Cygwin and release
it as a minimal Cygwin dll. This idea is probably ***stupid***.

Another possible solution is http://debian-cygwin.sourceforge.net/ project,
which tries to port dpkg to Windows. If it was possible to release Cygwin
using dpkg, we could create a comprehensive Cygwin + PostgreSQL on-line
installer.

Why look for complicated solutions when the only real issue for users is the
Cygwin installer?

Cheers,
Jean-Michel POURE

Le Mercredi 8 Mai 2002 06:03, Marc G. Fournier a écrit :
> Actually, there are licensing issues involved ... we could never put a
> 'windows binary' up for anon-ftp, since to distribute it would require the
> cygwin.dll to be distributed, and to do that, there is a licensing cost
> ... of course, I guess we could require ppl to download cygwin seperately,
> install that, then install the binary over top of that ...

This is an installer problem. Let's port dpkg to Windows, create a minimal
Cygwin dpkg distribution .. et voilà.

On Wed, 2002-05-08 at 14:02, Jean-Michel POURE wrote:
> Le Mardi 7 Mai 2002 20:32, mlw a écrit :
> > Since RedHat owns cygwin and they want RedHat database to be a success,
> > maybe they can make an exception to the GNU license for PostgreSQL.
>
> Cygwin received contributions from several authors. To leave a GNU licence,
> you need to get the agreement of all authors, which is not possible for a big
> project like Cygwin.
>
> Alternatively, you could pick-up the old static version of Cygwin and release
> it as a minimal Cygwin dll. This idea is probably ***stupid***.
>
> Another possible solution is http://debian-cygwin.sourceforge.net/ project,
> which tries to port dpkg to Windows. If it was possible to release Cygwin
> using dpkg, we could create a comprehensive Cygwin + PostgreSQL on-line
> installer.
>
> Why look for complicated solutions when the only real issue for users is the
> Cygwin installer?

IIRC the initial issue was bad performance, which was attributed to
win32/cygwin fork() behaviour.

That was long before this thread started.

BTW, does anyone know how other real databases (Oracle, DB2,
Interbase/Firebird, Infomix) do it on Windows.

-------------
Hannu

On Wed, 8 May 2002 01:03:37 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org> wrote:
> On Tue, 7 May 2002, Tom Lane wrote:
> 
> > It'd be worth trying to understand cygwin issues in detail before we
> > sign up to do and support a native Windows port.  I understand the
> > user-friendliness objection to cygwin (though one would think proper
> > packaging might largely hide cygwin from naive Windows users).  What I
> > don't understand is whether there are any serious performance lossages
> > from it, and if so whether we could work around them.
> 
> Actually, there are licensing issues involved ... we could never put a
> 'windows binary' up for anon-ftp, since to distribute it would require the
> cygwin.dll to be distributed, and to do that, there is a licensing cost

Why? Isn't Cyygwin GPL'd? From http://cygwin.com/licensing.html I don't
see anything that would require licensing fees for OSD-compliant software.

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Tom Lane
> Sent: Tuesday, May 07, 2002 1:49 PM
> To: mlw
> Cc: Marc G. Fournier; PostgreSQL-development
> Subject: Re: [HACKERS] How much work is a native Windows application?
>
>
> It'd be worth trying to understand cygwin issues in detail before we
> sign up to do and support a native Windows port.  I understand the
> user-friendliness objection to cygwin (though one would think proper
> packaging might largely hide cygwin from naive Windows users).  What
> I don't understand is whether there are any serious performance lossages
> from it, and if so whether we could work around them.

I've sent others to do a cygwin install of PG; it's not at all obvious to
them how much of cygwin they need & they end up installing ALL of cygwin (a
ton of devel tools, obscure unix utils, etc.) just to get PG working.

It would seem not too difficult to package up the cygwin.dll, the handful of
shell utils (sh, rm, etc.) req'd by PG, and perhaps even give it a standard
Windows installer.

Would this be a worthwhile move?

Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant

On Wed, 8 May 2002, Neil Conway wrote:

> On Wed, 8 May 2002 01:03:37 -0300 (ADT)
> "Marc G. Fournier" <scrappy@hub.org> wrote:
> > On Tue, 7 May 2002, Tom Lane wrote:
> >
> > > It'd be worth trying to understand cygwin issues in detail before we
> > > sign up to do and support a native Windows port.  I understand the
> > > user-friendliness objection to cygwin (though one would think proper
> > > packaging might largely hide cygwin from naive Windows users).  What I
> > > don't understand is whether there are any serious performance lossages
> > > from it, and if so whether we could work around them.
> >
> > Actually, there are licensing issues involved ... we could never put a
> > 'windows binary' up for anon-ftp, since to distribute it would require the
> > cygwin.dll to be distributed, and to do that, there is a licensing cost
>
> Why? Isn't Cyygwin GPL'd? From http://cygwin.com/licensing.html I don't
> see anything that would require licensing fees for OSD-compliant software.

I may be wrong about this ... this was prior to Redhat buying it out,
which I totally forgot about ...

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Marc G. Fournier
> Sent: Wednesday, May 08, 2002 12:04 AM
> To: Tom Lane
> Cc: mlw; PostgreSQL-development
> Subject: Re: [HACKERS] How much work is a native Windows application?
>
>
> On Tue, 7 May 2002, Tom Lane wrote:
>
> > It'd be worth trying to understand cygwin issues in detail before we
> > sign up to do and support a native Windows port.  I understand the
> > user-friendliness objection to cygwin (though one would think proper
> > packaging might largely hide cygwin from naive Windows users).  What I
> > don't understand is whether there are any serious performance lossages
> > from it, and if so whether we could work around them.
>
> Actually, there are licensing issues involved ... we could never put a
> 'windows binary' up for anon-ftp, since to distribute it would require the
> cygwin.dll to be distributed, and to do that, there is a licensing cost
> ... of course, I guess we could require ppl to download cygwin seperately,
> install that, then install the binary over top of that ...


From http://cygwin.com/licensing.html:

"""
In accordance with section 10 of the GPL, Red Hat permits programs whose
sources are distributed under a license that complies with the Open Source
definition to be linked with libcygwin.a without libcygwin.a itself causing
the resulting program to be covered by the GNU GPL.

This means that you can port an Open Source(tm) application to cygwin, and
distribute that executable as if it didn't include a copy of libcygwin.a
linked into it. Note that this does not apply to the cygwin DLL itself. If
you distribute a (possibly modified) version of the DLL you must adhere to
the terms of the GPL, i.e. you must provide sources for the cygwin DLL.

See http://www.opensource.org/osd.html for the precise Open Source
Definition referenced above.
"""

Not following this exactly, but would this give PG the exception it needs
(my eyes start to glaze over on stuff like this)? Anyone from RedHat still
on this list?

In any event, if PG can't release a PG+Cygwin in one package, we could
maintain a official web page about how to get PG running under Cygwin that
walks through exactly what to install, how to install, and how to set up.

There are some notes at http://www.ca.postgresql.org/docs/faq-mswin.html,
but these are assuming that you want to build PG, rather than simply install
PG from the cygwin packages.

I'd be very willing to help with this effort, once there's some consensus on
what direction we want to head.

- J.

Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant

"Marc G. Fournier" <scrappy@hub.org> writes:

> On Tue, 7 May 2002, Tom Lane wrote:
> 
> > It'd be worth trying to understand cygwin issues in detail before we
> > sign up to do and support a native Windows port.  I understand the
> > user-friendliness objection to cygwin (though one would think proper
> > packaging might largely hide cygwin from naive Windows users).  What I
> > don't understand is whether there are any serious performance lossages
> > from it, and if so whether we could work around them.
> 
> Actually, there are licensing issues involved ... we could never put
> a 'windows binary' up for anon-ftp, since to distribute it would
> require the cygwin.dll to be distributed, and to do that, there is a
> licensing cost ... of course, I guess we could require ppl to
> download cygwin seperately, install that, then install the binary
> over top of that ...

From the Cygwin FAQ:
       Is it free software?
       Yes. Parts are GNU software (gcc, gas, ld, etc...), parts are       covered by the standard X11 license, some of
itis public       domain, some of it was written by Cygnus and placed under the       GPL. None of it is shareware. You
don'thave to pay anyone to       use it but you should be sure to read the copyright section of       the FAQ more more
informationon how the GNU General Public       License may affect your use of these tools.
 

There is even a clause allowing you to link to the cygwin dll without
your software falling under the GPL if your software is released under
a license that complies with the Open Source Definition.
       *** NOTE ***
       In accordance with section 10 of the GPL, Red Hat permits       programs whose sources are distributed under a
licensethat       complies with the Open Source definition to be linked with       libcygwin.a without libcygwin.a
itselfcausing the resulting       program to be covered by the GNU GPL.
 
       This means that you can port an Open Source(tm) application to       cygwin, and distribute that executable as
ifit didn't include       a copy of libcygwin.a linked into it. Note that this does not       apply to the cygwin DLL
itself.If you distribute a (possibly       modified) version of the DLL you must adhere to the terms of       the GPL,
i.e.you must provide sources for the cygwin DLL.
 
       See http://www.opensource.org/osd.html for the precise Open       Source Definition referenced above.
       Red Hat sells a special Cygwin License for customers who are       unable to provide their application in open
sourcecode       form. For more information, please see:       http://www.redhat.com/software/tools/cygwin/, or call
  866-2REDHAT ext. 3007
 

In other words, you could even distribute a BSD licensed PostgreSQL
that that ran on Windows.  Not that such a loophole is particularly
useful.  GPL projects regularly include BSD code, this doesn't make
the BSD version GPLed.  The GPL might be viral in nature, but it's not
that viral.

Now, I can understand why the PostgreSQL mirrors might be a little bit
concerned about distributing GPLed software, because of the legal
ramifications, but they could leave the distribution of Cygwin up to
RedHat, and simply distribute a BSD-licensed PostgreSQL Windows
binary.

Jason

On Tue, May 07, 2002 at 01:16:01PM -0400, mlw wrote:
> I mentioned in another thread, Windows does not support "fork()."  PostgreSQL
> seems irrevocably tied to using fork(). Without a drastic rewrite of how
> postmaster works, I don't see a way to make a pure Windows version.
I watch this discussion and only one question is still in my head:how much people use Windows for server side part of
stableapplication based Oracle or DB2? Why my employer spend a lot of money withSGI cluster + IRIX?
 
_IMHO_ if you want support Windows, please, write good tools for admins, DB designers and developers (forms?). The
serveris really not a problem if you think about real DB application. There is more important things in ourTODO than
supportGUI-OS for server running... (IMHO:-)   Karel
 

-- Karel Zak  <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz,
http://mape.jcu.cz

Le Jeudi 9 Mai 2002 09:25, Karel Zak a écrit :
>  _IMHO_ if you want support Windows, please, write good tools for admins,
>  DB designers and developers (forms?). The server is really not a problem
> if you think about real DB application. There is more important things in
> our TODO than support GUI-OS for server running... (IMHO:-)
Try pgAdmin2 (http://pgadmin.postgresql.org. Other project are in the hub.
Mono port for example.

Tom Lane wrote:
> "Marc G. Fournier" <scrappy@hub.org> writes:
> > On Tue, 7 May 2002, Tom Lane wrote:
> >> It'd be worth trying to understand cygwin issues in detail before we
> >> sign up to do and support a native Windows port.
>
> > Actually, there are licensing issues involved ... we could never put a
> > 'windows binary' up for anon-ftp, since to distribute it would require the
> > cygwin.dll to be distributed, and to do that, there is a licensing cost
> > ... of course, I guess we could require ppl to download cygwin seperately,
> > install that, then install the binary over top of that ...
>
> <<itch>>  And how much development time are we supposed to expend to
> avoid that?
>
> Give me a technical case for avoiding Cygwin, and maybe I can get
> excited about it.  I'm not planning to lift a finger on the basis
> of licensing though... after all, Windows users are accustomed to
> paying for software, no?
   Nobody  asked  you  to lift any of your fingers. A few people   (including me) just see  value  in  a  native
Windows port,   kicking out the Cygwin requirement.
 
   I have the impression you never did use Cygwin. I did, thanks   but no thanks.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

Jan Wieck wrote:
> 
> Tom Lane wrote:
> > "Marc G. Fournier" <scrappy@hub.org> writes:
> > > On Tue, 7 May 2002, Tom Lane wrote:
> > >> It'd be worth trying to understand cygwin issues in detail before we
> > >> sign up to do and support a native Windows port.
> >
> > > Actually, there are licensing issues involved ... we could never put a
> > > 'windows binary' up for anon-ftp, since to distribute it would require the
> > > cygwin.dll to be distributed, and to do that, there is a licensing cost
> > > ... of course, I guess we could require ppl to download cygwin seperately,
> > > install that, then install the binary over top of that ...
> >
> > <<itch>>  And how much development time are we supposed to expend to
> > avoid that?
> >
> > Give me a technical case for avoiding Cygwin, and maybe I can get
> > excited about it.  I'm not planning to lift a finger on the basis
> > of licensing though... after all, Windows users are accustomed to
> > paying for software, no?
> 
>     Nobody  asked  you  to lift any of your fingers. A few people
>     (including me) just see  value  in  a  native  Windows  port,
>     kicking out the Cygwin requirement.
> 
>     I have the impression you never did use Cygwin. I did, thanks
>     but no thanks.

I have used the cygwin version too. It is a waste of time. No Windows user will
ever accept it. No windows-only user is going to use the cygwin tools. From a
production stand point, would anyone reading this trust their data to
PostgreSQL running on cygwin? Think about it, if you wouldn't, why would anyone
else.

I think, and I know people are probably sick of me spouting opinions, that if
you want a Windows presence for PostgreSQL, then we should write a real Win32
version.

If the global/static variables which are initialized by the postmaster are
moved to a structure, we can should be able to remove the fork() requirement
and port to a Win32 native system.

Jan Wieck writes:> Tom Lane wrote:> > Give me a technical case for avoiding Cygwin, and maybe I can get> > excited
aboutit.  I'm not planning to lift a finger on the basis> > of licensing though... after all, Windows users are
accustomedto> > paying for software, no?>     Nobody  asked  you  to lift any of your fingers. A few people>
(includingme) just see  value  in  a  native  Windows  port,>     kicking out the Cygwin requirement.>     I have the
impressionyou never did use Cygwin. I did, thanks>     but no thanks.
 

I think the crux of the the problem is that a native Windows port
would require a LOT of changes in the source (switching over to API
wrappers, adding compatibility layers). Obviously this has the
possibility of introducing a lot of bugs with zero gain for the folk
who are already happily running PostgreSQL on UNIX-like systems. And
what of performance?

Sure It'd be nice to have a native PostgreSQL on XP Server (I don't
see the point in consumer level Microsoft OSs) but how high is the
demand? What's the prize? What are the current limitations - fork,
semaphores, ugly interface...?

Lee.

mlw <markw@mohawksoft.com> writes:
> I have used the cygwin version too. It is a waste of time. No Windows user will
> ever accept it. No windows-only user is going to use the cygwin tools.

With decent packaging, no windows-only user would even know we have
cygwin in there.  The above argument is just plain irrelevant.  The real
point is that we need a nice clean friendly GUI for both installation
and administration --- and AFAICS that will take about the same amount of
work to write whether the server requires cygwin internally or not.

Rather than expending largely-pointless work on internal rewrites of
the server, people who care about this issue ought to be thinking about
the GUI problems.

> From a production stand point, would anyone reading this trust their
> data to PostgreSQL running on cygwin?

I wouldn't trust my data to *any* database running on a Microsoft OS.
Period.  The above argument thus doesn't impress me at all, especially
when it's being made without offering a shred of evidence that cygwin
contributes any major degree of instability.

I am especially unhappy about the prospect of major code revisions
and development time spent on chasing this rather than improving our
performance and stability on Unix-type OSes.  I agree with the comment
someone else made: that's just playing Microsoft's game.
        regards, tom lane

Lee Kindness wrote:

> 
> Sure It'd be nice to have a native PostgreSQL on XP Server (I don't
> see the point in consumer level Microsoft OSs) but how high is the
> demand? What's the prize? What are the current limitations - fork,
> semaphores, ugly interface...?

The demand for PostgreSQL on Windows is currently as near to zero as you can
imagine. This is probably because there is no viable PostgreSQL on Windows.

If written correctly, a Win32 version of PostgreSQL would rock the Windows
world. I see no reason why it would be limted to the "professional" version.
Hell, it could even run on Windows 98.

Right now, in the small to medium space, there is only one choice for Windows,
MSSQL. It requires the "professional" or server versions of the Microsoft
platforms. PostgreSQL could come in and run on all of them. 

PostgreSQL's feature set and price ($0), with a good installer, would do VERY
well.

Tom Lane wrote:
> With decent packaging, no windows-only user would even know we have
> cygwin in there.  The above argument is just plain irrelevant.  The real
> point is that we need a nice clean friendly GUI for both installation
> and administration --- and AFAICS that will take about the same amount of
> work to write whether the server requires cygwin internally or not.

Can a cygwin version of PostgreSQL see the native file system, like: C:\My
Database, D:\postgres?

> > From a production stand point, would anyone reading this trust their
> > data to PostgreSQL running on cygwin?
> 
> I wouldn't trust my data to *any* database running on a Microsoft OS.

That is a prejudice that is affecting your judgment. Many people do trust
Windows, do I? No, but a lot of people do. People have trusted their businesses
on Windows NT/2K/XP, many are still doing so. We want these people to use
PostgreSQL, so when they see the error in their ways, they have a way out.


> The above argument thus doesn't impress me at all, especially
> when it's being made without offering a shred of evidence that cygwin
> contributes any major degree of instability.

From a software development standpoint, I am VERY uncomfortable with the
technique of a user space program copying its writeable memory to another
process's. It may work until Microsoft changes something with the next version
of IE. What about anti-virus software, cygwin has problems with them, and you
have to have anti-virus software on Windows.

On top of that, the time spent copying the whole process is too long, and it
forces real memory to be allocated and initialized at process startup. 

So, the cygwin fork() will cause PostgreSQL to be slower and use more memory
than a native version, and will not co-exist well with anti-virus software.

> 
> I am especially unhappy about the prospect of major code revisions
> and development time spent on chasing this rather than improving our
> performance and stability on Unix-type OSes.  I agree with the comment
> someone else made: that's just playing Microsoft's game.

Maybe is is playing "Microsoft's Game" but the end result will be a program
that can seriously compete with MSSQL on Windows, and provide a REAL migration
path to UNIX. 

Many developers use MSSQL because they "have it" in MSDN, so to them, it is
free. Once they develop something using it, they are tied to Windows. When it
comes time to deploy their pet project, the company has to cough up the price
of the server.

A native, friendly, Win32 PostgreSQL that works the same on Windows as it does
on FreeBSD, Linux, Solaris, etc. Will offer the developer real options away
from Windows.

Also: I don't think it needs to be a major rewrite, no strategy needs to
change, it is basically renaming variables, i.e. my_global_var becomes
pg_globals.my_global_var.

Once that is done, a port writer can do what ever they need to do to get that
structure to the child correctly. As an exercise, I bet if we did this, we
would find bugs which are lurking, as yet unfound.

Besides, the discipline of using a globals structure will improve the code
base. Don't you agree?

...
> PostgreSQL's feature set and price ($0), with a good installer, would do VERY
> well.

That may be (I'd like to think so!).

We've identified at least a couple of barriers to folks running
PostgreSQL on Windows. The installer and GUI issue needs to be solved no
matter what, and we *could* have a version running on Windows with just
those things in place.

imho if we are going down the path, we need to take the first steps. And
those do *not* require code rewrites to do so (or at least don't appear
to).

If we had a package available for Windows -- with some developers such
as yourself supporting it -- then we could talk about putting more
resources into supporting that platform better. But the perception of at
least some of the key developers (including myself) is that *if* we did
the code rewrite, and *if* we spent the effort to end up as a native on
Windows, then we *very well might* be an unreliable database on an
unreliable platform.

istm that getting a well packaged system running now, then being able to
identify *only cygwin* as the barrier to better reliability would get
more support for changes in the backend code.

And if we were working toward some ability to do threading anyway (I
don't see that in the near future, but we've talked in the past about
structuring the query engine around "tuple sources" which could then be
distributed across threads or across machines) then maybe the next step
is easier.

My 2c...
                       - Thomas

There are some issues that the whole idea of a win32 port should bring up.  
One of them is whether or not postgresql should be rewritten as a 
multi-threaded app.

If postgresql will never be rewritten as a multi-threaded app, then 
performance under Windows is likely to ALWAYS be slow, since that 
multi-thread is the preferred model for good performance on W32.  note 
that many Unixes prefer multi-threaded models as well (Solaris comes to 
mind) so there's the possibility that a multi-threaded postgresql could 
enjoy better performance on more than just windows.

If postgresql IS going to eventually be multi-threaded, then the whole 
win32 port should probably be delayed until then, since it would solve 
many of the issues of fork() versus createprocess().

Just my thoughts on it.

Scott

mlw wrote:
> I think, and I know people are probably sick of me spouting opinions, that if
> you want a Windows presence for PostgreSQL, then we should write a real Win32
> version.
>
> If the global/static variables which are initialized by the postmaster are
> moved to a structure, we can should be able to remove the fork() requirement
> and port to a Win32 native system.
   My  opinion  here is that until May 1998 Postgres did exec(),   so it was clean and okay for CreateProcess() up to
then.Just   because  we  optimized  it  for  the copy-on-write behaviour,   modern Unix kernels do with fork()  only,
is NO  reason  to   accept  sloppy  coding.  The  Postmaster and the backend have   different responsibilities. In
fact,I  still  consider  them   beeing   different  programs  even  if  they  reside  in  one   executable. Mixing
globalvariables of one with the other  is   wrong.
 


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

mlw wrote:
> Can a cygwin version of PostgreSQL see the native file system, like: C:\My
> Database, D:\postgres?

Sort of.  C:\My Database
becomes  /cygdrive/c/My Database
under cygwin.  So the path names need to be munged, but you can access 
the entire windows filesystem from within cygwin.

--Barry

> Lee Kindness wrote:
>> Sure It'd be nice to have a native PostgreSQL on XP Server (I don't
>> see the point in consumer level Microsoft OSs) but how high is the
>> demand? What's the prize? What are the current limitations - fork,
>> semaphores, ugly interface...?

> The demand for PostgreSQL on Windows is currently as near to zero
> as you can imagine. This is probably because there is no viable
> PostgreSQL on Windows.
>
> If written correctly, a Win32 version of PostgreSQL would rock
> the Windows world. I see no reason why it would be limted to the
> "professional" version. Hell, it could even run on Windows 98.
>
> Right now, in the small to medium space, there is only one choice for
> Windows, MSSQL. It requires the "professional" or server versions of
> the Microsoft platforms. PostgreSQL could come in and run on all of
> them.
>
> PostgreSQL's feature set and price ($0), with a good installer, would
> do VERY well.

If "fixing" PostgreSQL to "work" on Win32 caused a whole lot of breakage on the Unix side, that would _not_ be a "win."
It might do well on Win32, but breakage could lead to a LOSS of interest on Unix, as people decided to take the point
ofview that the developers considered it more important to toady to Win-Needs than to improve how it works on Unix.
 

Is that a totally "fair" point of view?  No, but in a world where New York office buildings get bombed resulting in
absolutelybizarre combinations of cheering and jeering, an expectation of "fairness" is definitely too much to ask.
(Youwon't get anything resembling "fairness" at the airport, that's for sure...)
 

How about a totally different perspective:   Why not let someone else go after the Windows "market"?

People are actively working on SAP-DB and Firebird, and putting pretty serious efforts into the Win32 side of those
databasesystems.  How outrageous an idea is it to say: "Let them deal with that set of headaches?"
 

Aside from that, there's also the "Show me the patch" option.  If someone is excited about porting PostgreSQL to Win32,
nothingis stopping them from doing so, and contributing patches back.  There seem to be several such efforts out there;
ifone becomes mature enough, it may represent a useful basis to port in to make the main codebase "more portable."
 

There are at least the two clear options: 
- Other DBs;
- Volunteers porting PostgreSQL to Win32.

If a "winner" emerges, that would surely be useful to guide later PostgreSQL efforts.
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://www.cbbrowne.com/info/wp.html
"What  you end  up with,  after  running an  operating system  concept
through these  many marketing coffee filters, is  something not unlike
plain hot water."  -- Matt Welsh
-- 
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/sap.html
"I'm not switching from slrn.   I'm quite confident that anything that
*needs* to be posted in HTML is fatuous garbage not worth my time."
-- David M. Cook <davecook@home.com>

> I think, and I know people are probably sick of me spouting opinions,
> that if you want a Windows presence for PostgreSQL, then we should
> write a real Win32 version.

The crucial wrong word is the word "we."

If _you_ want a Windows presence, then _you_ should write a real Win32 
version.  That clearly attaches responsibility to someone who is interested.
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://www.cbbrowne.com/info/unix.html
"I'm not switching from slrn.   I'm quite confident that anything that
*needs* to be posted in HTML is fatuous garbage not worth my time."
-- David M. Cook <davecook@home.com>

-- 
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/spreadsheets.html
Rules of the Evil Overlord #166.  "If the rebels manage to trick me, I
will make a  note of what they did  so that I do not  keep falling for
the same trick over and over again." <http://www.eviloverlord.com/>

cbbrowne@cbbrowne.com wrote:
> 
> > I think, and I know people are probably sick of me spouting opinions,
> > that if you want a Windows presence for PostgreSQL, then we should
> > write a real Win32 version.
> 
> The crucial wrong word is the word "we."
> 
> If _you_ want a Windows presence, then _you_ should write a real Win32
> version.  That clearly attaches responsibility to someone who is interested.

I have already said that I am willing to write the pieces for a Windows port.
The issue is changes in PostgreSQL required to do it.

Christopher Browne wrote:
> 
> If "fixing" PostgreSQL to "work" on Win32 caused a whole lot of
> breakage on the Unix side, that would _not_ be a "win."  It might
> do well on Win32, but breakage could lead to a LOSS of interest
> on Unix, as people decided to take the point of view that the
> developers considered it more important to toady to Win-Needs
> than to improve how it works on Unix.
As a PostgreSQL user, I *wholeheartedly* agree.  I have no need nor
interest in a Win32 solution.  Period.  If I perceive that an effort
to add a Win32 postgresql is adversely impacting the ongoing
development of Unix-based PostgreSQL then I will start looking at
other solutions.

In fact, if you folks could find additional resources that would
support Win32 development, it still seems to me that perhaps those
resources could be better spent improving the Unix version.

-- 
Steve Wampler -- swampler@noao.edu
O sibile, si ergo.  Fortibus es enaro.
Nobile, demis trux.  Demis phulla causan dux.

Scott Marlowe wrote:
> 
> There are some issues that the whole idea of a win32 port should bring up.
> One of them is whether or not postgresql should be rewritten as a
> multi-threaded app.

Perhaps.

> 
> If postgresql will never be rewritten as a multi-threaded app, then
> performance under Windows is likely to ALWAYS be slow, since that
> multi-thread is the preferred model for good performance on W32.

There are methods for reducing process creation load on Windows. One way is to
make PostgreSQL one big .DLL and just spin off a small program. A windows .DLL
is different than a UNIX shared library, in some ways better, in other ways
worse, either way, it is a usefull tool.


>  note
> that many Unixes prefer multi-threaded models as well (Solaris comes to
> mind) so there's the possibility that a multi-threaded postgresql could
> enjoy better performance on more than just windows.

The isolation of a process is very important to reliable operation. Going
threaded usually means allowing a single connection to bring down the whole
server.

Le Jeudi 9 Mai 2002 16:55, mlw a écrit :
> Can a cygwin version of PostgreSQL see the native file system, like: C:\My
> Database, D:\postgres?

You have the choice to keep Windows or Unix paths. Both are supported.
/Jean-Michel POURE

> cbbrowne@cbbrowne.com wrote:
>>> I think, and I know people are probably sick of me spouting
>>> opinions, that if you want a Windows presence for PostgreSQL, then
>>> we should write a real Win32 version.
>>
>> The crucial wrong word is the word "we."

>> If _you_ want a Windows presence, then _you_ should write a real
>> Win32 version.  That clearly attaches responsibility to someone who
>> is interested.

> I have already said that I am willing to write the pieces for a
> Windows port.  The issue is changes in PostgreSQL required to do it.

No, I don't think you understand.

If you're planning to do a port, then _all_ changes are your
responsibility.  Nobody ought to need to change PostgreSQL in order for
you to write a Windows port; that, in fact, would be a waste of time,
having several people working on something that should probably be done
by one person.
--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://www.ntlug.org/~cbbrowne/x.html
Why are they called apartments, when they're all stuck together? 

Scott Marlowe wrote:
> There are some issues that the whole idea of a win32 port should bring up.
> One of them is whether or not postgresql should be rewritten as a
> multi-threaded app.
   Please, don't add this one to it.
   I'm  all for the native Windows port, yes, but I've discussed   the multi-thread questions for days  at  Great
Bridge, then   again with my new employer, with people on shows and whatnot.
 
   Anything in the whole  backend  is  designed  with  a  multi-   process  model in mind.  You'll not do that in any
reasonable  amount of time.
 

> If postgresql will never be rewritten as a multi-threaded app, then
> performance under Windows is likely to ALWAYS be slow, since that
> multi-thread is the preferred model for good performance on W32.  note
> that many Unixes prefer multi-threaded models as well (Solaris comes to
> mind) so there's the possibility that a multi-threaded postgresql could
> enjoy better performance on more than just windows.
   As soon as you switch to a multi-threaded middle  tier,  that   uses connection pools and avoids constant process
creation,I   think you don't have much of a problem  any  more.  The  high   connect/disconnect  ratio, acceptable for
threadeddatabases,   is what kills PostgreSQL.
 

> If postgresql IS going to eventually be multi-threaded, then the whole
> win32 port should probably be delayed until then, since it would solve
> many of the issues of fork() versus createprocess().
   If multi-threading is the plan, then there is  light  at  the   end of the tunnel ... the upcoming train...


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

On Thu, 9 May 2002, Jan Wieck wrote:

> > If postgresql IS going to eventually be multi-threaded, then the whole
> > win32 port should probably be delayed until then, since it would solve
> > many of the issues of fork() versus createprocess().
> 
>     If multi-threading is the plan, then there is  light  at  the
>     end of the tunnel ... the upcoming train...

That's a bit extreme don't you think?  I'm not fan of multi-threading as 
the one true way, and since I use linux as my server for postgresql, there 
is no gain for me in a multi-threaded model.  In fact, I'd prefer 
postgresql stay multi-process for robustness.

BUT, if there are plans to go multi-thread, or could be plans, then those 
should take priority over how to port to windows, since making postgresql 
multi-threaded will change it so much as to make the current "how do we 
port to windows" thread meaningless.

One of the primary reasons given for avoiding cygwin is that postgresql 
runs so slowly under it on windows, but I submit that it probably won't 
run a heck of a lot faster if it was written as a native app as long as 
it's running as a multi-process design.  Since there's probably no great 
gain to be had from moving it out from under cygwin, why bother?

My vote would be to stay multi-process and Unix compatible.  I have no 
real use for windows as a server, and do NOT want to sacrifice the 
performance / reliability I have with postgresql under Linux for a windows 
port.

cbbrowne@cbbrowne.com wrote:
> 
> > cbbrowne@cbbrowne.com wrote:
> >>> I think, and I know people are probably sick of me spouting
> >>> opinions, that if you want a Windows presence for PostgreSQL, then
> >>> we should write a real Win32 version.
> >>
> >> The crucial wrong word is the word "we."
> 
> >> If _you_ want a Windows presence, then _you_ should write a real
> >> Win32 version.  That clearly attaches responsibility to someone who
> >> is interested.
> 
> > I have already said that I am willing to write the pieces for a
> > Windows port.  The issue is changes in PostgreSQL required to do it.
> 
> No, I don't think you understand.
> 
> If you're planning to do a port, then _all_ changes are your
> responsibility.  Nobody ought to need to change PostgreSQL in order for
> you to write a Windows port; that, in fact, would be a waste of time,
> having several people working on something that should probably be done
> by one person.

Without buy-in from the group, there is no point in me wasting my time doing
all the work necessary. I'm not interested in making Mark's special version of
PostgreSQL.

If we can agree on a strategy and a course, then it is worth doing. If all the
changes made fall on the floor because the group does not like them, then I
wasted my time. Got it?

Also, doing the Windows portions of the code will represent a significant
investment of my time. I'm not interested in doing a lot of work on a shoddy
project. If you ask the core group to put out a crappy version of PostgreSQL
for a UNIX, they would fight long and hard against it. Why should we be willing
to produce a crappy version for Windows, just because the people here don't
like Windows.

I don't care about Solaris, but I understand WHY it is important to make
PostgreSQL work well on it. I don't understand why the people in this group
don't see the same purpose for a Windows port. To be honest, I think a good
Windows port will do wonders for PostgreSQL's acceptance.

cbbrowne@cbbrowne.com wrote:
> > cbbrowne@cbbrowne.com wrote:
> >>> I think, and I know people are probably sick of me spouting
> >>> opinions, that if you want a Windows presence for PostgreSQL, then
> >>> we should write a real Win32 version.
> >>
> >> The crucial wrong word is the word "we."
>
> >> If _you_ want a Windows presence, then _you_ should write a real
> >> Win32 version.  That clearly attaches responsibility to someone who
> >> is interested.
>
> > I have already said that I am willing to write the pieces for a
> > Windows port.  The issue is changes in PostgreSQL required to do it.
>
> No, I don't think you understand.
>
> If you're planning to do a port, then _all_ changes are your
> responsibility.  Nobody ought to need to change PostgreSQL in order for
> you to write a Windows port; that, in fact, would be a waste of time,
> having several people working on something that should probably be done
> by one person.
   Who  said PostgreSQL shall not support any other OS than *NIX   or things that look alike?
   When I first used Postgres, it still had a VMS  port.   Well,   we  dropped  the VMS port at some point, when we
wherepretty   sure it was broken and nobody complained.
 
   Now we  face  the  fact  that  Microsoft  managed  to  create   something  useful  (other than a joystick or optical
mouse,I   mean Win2K).  And as a  logical  consequence  more  and  more   people ask for support of their OS.
 
   A  good  deal  of  effort  in the original Postgres was about   portability.  I hope we've not become a UNIX-only
show.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

On Thu, 2002-05-09 at 22:36, mlw wrote:
> Scott Marlowe wrote:
> >  note
> > that many Unixes prefer multi-threaded models as well (Solaris comes to
> > mind) so there's the possibility that a multi-threaded postgresql could
> > enjoy better performance on more than just windows.
> 
> The isolation of a process is very important to reliable operation. Going
> threaded usually means allowing a single connection to bring down the whole
> server.

AFAIK we do that already in forked model - any time postmaster thinks
that a dying child has corrupted shared memory it kills all its
children.

--------
Hannu

On Thu, 2002-05-09 at 22:51, Jan Wieck wrote:
> Scott Marlowe wrote:
> > There are some issues that the whole idea of a win32 port should bring up.
> > One of them is whether or not postgresql should be rewritten as a
> > multi-threaded app.
> 
>     Please, don't add this one to it.
> 
>     I'm  all for the native Windows port, yes, but I've discussed
>     the multi-thread questions for days  at  Great  Bridge,  then
>     again with my new employer, with people on shows and whatnot.
> 
>     Anything in the whole  backend  is  designed  with  a  multi-
>     process  model in mind.  You'll not do that in any reasonable
>     amount of time.

IIRC you are replying to the man who _has_ actually don this ?

Perhaps using an unreasonable amount of time but still ... :)

----------
Hannu

Hannu Krosing wrote:
> 
> On Thu, 2002-05-09 at 22:36, mlw wrote:
> > Scott Marlowe wrote:
> > >  note
> > > that many Unixes prefer multi-threaded models as well (Solaris comes to
> > > mind) so there's the possibility that a multi-threaded postgresql could
> > > enjoy better performance on more than just windows.
> >
> > The isolation of a process is very important to reliable operation. Going
> > threaded usually means allowing a single connection to bring down the whole
> > server.
> 
> AFAIK we do that already in forked model - any time postmaster thinks
> that a dying child has corrupted shared memory it kills all its
> children.

I know there are cases when postmaster will kill all its children, but take the
case of a faulty user function that gets a segfault. That process dies and the
others continue. Without a lot of OS specific crap in postgres, that sort of
behavior would be difficult to have with a threaded server.

On Fri, 2002-05-10 at 00:09, Hannu Krosing wrote:
> On Thu, 2002-05-09 at 22:51, Jan Wieck wrote:
> > Scott Marlowe wrote:
> > > There are some issues that the whole idea of a win32 port should bring up.
> > > One of them is whether or not postgresql should be rewritten as a
> > > multi-threaded app.
> > 
> >     Please, don't add this one to it.
> > 
> >     I'm  all for the native Windows port, yes, but I've discussed
> >     the multi-thread questions for days  at  Great  Bridge,  then
> >     again with my new employer, with people on shows and whatnot.
> > 
> >     Anything in the whole  backend  is  designed  with  a  multi-
> >     process  model in mind.  You'll not do that in any reasonable
> >     amount of time.
> 
> IIRC you are replying to the man who _has_ actually don this ?

Sorry, mistaken identity. I meant Myron scott ( mkscott@sacadia.com )

who has made this http://sourceforge.net/projects/mtpgsql

> Perhaps using an unreasonable amount of time but still ... :)
> 
> ----------
> Hannu
> 

On Thu, 2002-05-09 at 19:23, mlw wrote:
> Lee Kindness wrote:
> 
> > 
> > Sure It'd be nice to have a native PostgreSQL on XP Server (I don't
> > see the point in consumer level Microsoft OSs) but how high is the
> > demand? What's the prize? What are the current limitations - fork,
> > semaphores, ugly interface...?
> 
> The demand for PostgreSQL on Windows is currently as near to zero as you can
> imagine. This is probably because there is no viable PostgreSQL on Windows.
> 
> If written correctly, a Win32 version of PostgreSQL would rock the Windows
> world. I see no reason why it would be limted to the "professional" version.
> Hell, it could even run on Windows 98.

Perhaps we could simpultaneously solve another problem - creating a
singlethreaded embeddable version of postgresql "engine"

-------------
Hannu

On Thu, 2002-05-09 at 19:25, Tom Lane wrote:
> mlw <markw@mohawksoft.com> writes:
> > I have used the cygwin version too. It is a waste of time. No Windows user will
> > ever accept it. No windows-only user is going to use the cygwin tools.
> 
> With decent packaging, no windows-only user would even know we have
> cygwin in there.  The above argument is just plain irrelevant.  The real
> point is that we need a nice clean friendly GUI for both installation
> and administration --- and AFAICS that will take about the same amount of
> work to write whether the server requires cygwin internally or not.

<evil grin>
We can go the Oracle way and write a 200MB cross-platform java installer
requiring and exact version of java runtime 
</evil grin>

> Rather than expending largely-pointless work on internal rewrites of
> the server, people who care about this issue ought to be thinking about
> the GUI problems.

pgAccess is quite nice (Disclaimer: I'm not a windows weenie, I run it
inside vmware/win98 IE browser test environment on my Linux workstation
;). 

Why not just bundle what we've got ?

> > From a production stand point, would anyone reading this trust their
> > data to PostgreSQL running on cygwin?
> 
> I wouldn't trust my data to *any* database running on a Microsoft OS.
> Period. 

Do we support Xenix and SCO ?

> The above argument thus doesn't impress me at all, especially
> when it's being made without offering a shred of evidence that cygwin
> contributes any major degree of instability.

From the comments here it seems to be either cygwin or more likely
cygipc

> I am especially unhappy about the prospect of major code revisions
> and development time spent on chasing this rather than improving our
> performance and stability on Unix-type OSes.  I agree with the comment
> someone else made: that's just playing Microsoft's game.

Not!

I think that this thread is mostly about coordinating code and interface
cleanups that are likely beneficial for both *NIX and non-*NIX platforms
mainly* cleaner support for semaphores* separating shared and per-process data* process creation* (file operations)*
(initand service scripts)
 
if done properly none of these will degrade code quality nor
performance.

Also, having a clean interface for those will not only enable any
interested party to make windows/BeOS/OSX/QNX binaries with less effort,
it will most likely make it easier make use of advances in *NIX world
like AIO, multiprocessor systems, NUMA and distributed systems, and just
make things more robust and reliable by making code inspection easier.

---------------
Hannu

Tom Lane <tgl@sss.pgh.pa.us> writes:

> mlw <markw@mohawksoft.com> writes:
> > I have used the cygwin version too. It is a waste of time. No Windows
user will
> > ever accept it. No windows-only user is going to use the cygwin tools.
>
> With decent packaging, no windows-only user would even know we have
> cygwin in there.  The above argument is just plain irrelevant.  The real
> point is that we need a nice clean friendly GUI for both installation
> and administration --- and AFAICS that will take about the same amount of
> work to write whether the server requires cygwin internally or not.

I'm afraid I agree with mlw, Tom. I don't think the problem ends at the GUI,
although for many people it would.  The issue extends at least also to
support and troubleshooting.  In a production environment, I have a better
chance of figuring out what's going wrong with an application written
natively for an operating system dealing directly with that operating
system. I would take a dim view of using PostgreSQL running on cygwin unless
I had extensive experience doing it, or if there were no other alternative.

> > From a production stand point, would anyone reading this trust their
> > data to PostgreSQL running on cygwin?
>
> I wouldn't trust my data to *any* database running on a Microsoft OS.
> Period.  The above argument thus doesn't impress me at all, especially
> when it's being made without offering a shred of evidence that cygwin
> contributes any major degree of instability.

If you could prove to me that cygwin doesn't contribute *any* instability,
I'd still be pretty worried, probably for the same reasons that you don't
trust any Microsoft OS. There are increased chances that something could go
critically wrong, particularly in an environment fundamentally different. I
think mlw's basic point is quite valid, that PG+cygwin will not ever find
favor with decision-makers who are used to Windows systems.  Suspicion of
the other environment's foibles is common, and goes both ways.

> I am especially unhappy about the prospect of major code revisions
> and development time spent on chasing this rather than improving our
> performance and stability on Unix-type OSes.  I agree with the comment
> someone else made: that's just playing Microsoft's game.

There I don't deny you may be right.

Ernie Gutierrez
Walnut Creek, CA