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.
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
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:
Show quoted text
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.
"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
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 costWhy? 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 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
-----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 ...
"""
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 it is public
domain, some of it was written by Cygnus and placed under the
GPL. None of it is shareware. You don't have to pay anyone to
use it but you should be sure to read the copyright section of
the FAQ more more information on 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 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.
Red Hat sells a special Cygwin License for customers who are
unable to provide their application in open source code
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 stable application
based Oracle or DB2? Why my employer spend a lot of money with
SGI cluster + IRIX?
_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:-)
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 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 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.
