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.
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.
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
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 global variables 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 of view 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 absolutely bizarre combinations of cheering and jeering, an expectation of "fairness" is definitely too much to ask. (You won'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 database systems. 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, nothing is stopping them from doing so, and contributing patches back. There seem to be several such efforts out there; if one 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 threaded databases,
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 where pretty
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
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
Show quoted text
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)
* (init and 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
On Fri, 2002-05-10 at 02:33, Dann Corbit wrote:
It took a few hundred man hours to do it.
About 2-8 weeks for one full time programmer ?
I see the whole Win32 port as
a non issue. Several parties have already completed it (including the
place where I work -- CONNX Solutions Inc.). If we did not do it or all
parties who already did it were hit by a comet or something, someone
else would accomplish it. It isn't trivial but it isn't impossible
either. If a need is large enough, someone will manage it. The need is
large enough. Ergo...
Do you know which of these run ((reasonably) well) on win9x ?
Here are some other things related:
A ready to go Win32 PosgreSQL package:
http://www.dbexperts.net/postgresql
Perhaps we should back up and let dbexperts et.al. recover their costs
and after that repent and commit changes back to main tree ;)
## insert a little ad-hominem attack to everyone objecting a native
## win32 port as owning stock in some win32-pg-selling company
BTW, do they have an evaluation version or do they think that people
would in that case evaluate on win32 and then buy a cheap linux box for
$495.- :)
--------------------
Hannu
Import Notes
Reply to msg id not found: D90A5A6C612A39408103E6ECDD77B82920CE10@voyager.corporate.connx.comReference msg id not found: D90A5A6C612A39408103E6ECDD77B82920CE10@voyager.corporate.connx.com | Resolved by subject fallback
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.
-----Original Message-----
From: Hannu Krosing [mailto:hannu@tm.ee]
Sent: Thursday, May 09, 2002 12:10 PM
To: Jan Wieck
Cc: Scott Marlowe; PostgreSQL-development
Subject: Re: [HACKERS] Issues tangential to win32 supportOn 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 ... :)
It took a few hundred man hours to do it. I see the whole Win32 port as
a non issue. Several parties have already completed it (including the
place where I work -- CONNX Solutions Inc.). If we did not do it or all
parties who already did it were hit by a comet or something, someone
else would accomplish it. It isn't trivial but it isn't impossible
either. If a need is large enough, someone will manage it. The need is
large enough. Ergo...
Here are some other things related:
A ready to go Win32 PosgreSQL package:
http://www.dbexperts.net/postgresql
An open source project to productize PostgreSQL for Windows (has gone
nowhere so far):
http://gborg.postgresql.org/project/winpackage/projdisplay.php
A native Win32 port accomplished by a Japanese Group:
http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html
If you look under the "Gists for Patch" it contains exactly the same
tasks that CONNX Solutions Inc. had to accomplish in every case.
Import Notes
Resolved by subject fallback
Dann Corbit wrote:
It took a few hundred man hours to do it. I see the whole Win32 port as
a non issue. Several parties have already completed it (including the
place where I work -- CONNX Solutions Inc.). If we did not do it or all
parties who already did it were hit by a comet or something, someone
else would accomplish it. It isn't trivial but it isn't impossible
either. If a need is large enough, someone will manage it. The need is
large enough. Ergo...Here are some other things related:
A ready to go Win32 PosgreSQL package:
http://www.dbexperts.net/postgresqlAn open source project to productize PostgreSQL for Windows (has gone
nowhere so far):
http://gborg.postgresql.org/project/winpackage/projdisplay.phpA native Win32 port accomplished by a Japanese Group:
http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html
If you look under the "Gists for Patch" it contains exactly the same
tasks that CONNX Solutions Inc. had to accomplish in every case.
These packages are based upon cygwin. Problems with cygwin:
(1) GNU license issues.
(2) Does not work well with anti-virus software
(3) Since OS level copy-on-write is negated, process creation is much slower.
(4) Since OS level copy on write is negated, memory that otherwise would not be
allocated to the process is forced to ba allocated when the parent process data
is copied.
-----Original Message-----
From: mlw [mailto:markw@mohawksoft.com]
Sent: Thursday, May 09, 2002 2:41 PM
To: Dann Corbit
Cc: PostgreSQL-development
Subject: Re: Issues tangential to win32 supportDann Corbit wrote:
It took a few hundred man hours to do it. I see the whole
Win32 port as
a non issue. Several parties have already completed it
(including the
place where I work -- CONNX Solutions Inc.). If we did not
do it or all
parties who already did it were hit by a comet or something, someone
else would accomplish it. It isn't trivial but it isn't impossible
either. If a need is large enough, someone will manage it.The need is
large enough. Ergo...
Here are some other things related:
A ready to go Win32 PosgreSQL package:
http://www.dbexperts.net/postgresqlAn open source project to productize PostgreSQL for Windows
(has gone
nowhere so far):
http://gborg.postgresql.org/project/winpackage/projdisplay.phpA native Win32 port accomplished by a Japanese Group:
http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html
If you look under the "Gists for Patch" it contains exactly the same
tasks that CONNX Solutions Inc. had to accomplish in every case.These packages are based upon cygwin. Problems with cygwin:
(1) GNU license issues.
(2) Does not work well with anti-virus software
(3) Since OS level copy-on-write is negated, process creation
is much slower.
(4) Since OS level copy on write is negated, memory that
otherwise would not be
allocated to the process is forced to ba allocated when the
parent process data
is copied.
Our package avoids Cygwin altogether. We wrote our own POSIX layer from
scratch, and we junked fork() for CreateProcess() {and inserted copious:
#ifdef ICKY_WIN32_KLUDGE
/* our code goes here */
#else
/* Standard UNIX code goes here */
#endif
It's complete, and it performs like the burning blue blazes. We have
run the full PostgreSQL test suite to completion with success. However,
before we release any SQL tool, we have our own test suite with tens of
thousands of tests to perform. Hence, we won't have a release until
June at the earliest.
I think the Japanese one also does not use Cygwin (but I have not tried
installing it yet).
Import Notes
Resolved by subject fallback
Dann Corbit wrote:
Our package avoids Cygwin altogether. We wrote our own POSIX layer from
scratch, and we junked fork() for CreateProcess() {and inserted copious:
#ifdef ICKY_WIN32_KLUDGE
/* our code goes here */
#else
/* Standard UNIX code goes here */
#endif
OK, what sorts of things did you do in your ICKY_WIN32_KLUDGE? Were they ever
migrated back into the main tree? Did you simulate fork() or a stand-alone?
I know Windows very well, but I have thus far remained ignorant of PostgreSQL
internals.
It's complete, and it performs like the burning blue blazes. We have
run the full PostgreSQL test suite to completion with success. However,
before we release any SQL tool, we have our own test suite with tens of
thousands of tests to perform. Hence, we won't have a release until
June at the earliest.I think the Japanese one also does not use Cygwin (but I have not tried
installing it yet).
The japanese site claims cygwin.
-----Original Message-----
From: mlw [mailto:markw@mohawksoft.com]
Sent: Thursday, May 09, 2002 2:56 PM
To: Dann Corbit
Cc: PostgreSQL-development
Subject: Re: Issues tangential to win32 supportDann Corbit wrote:
Our package avoids Cygwin altogether. We wrote our own
POSIX layer from
scratch, and we junked fork() for CreateProcess() {and
inserted copious:
#ifdef ICKY_WIN32_KLUDGE
/* our code goes here */
#else
/* Standard UNIX code goes here */
#endifOK, what sorts of things did you do in your
ICKY_WIN32_KLUDGE? Were they ever
migrated back into the main tree? Did you simulate fork() or
a stand-alone?
I explained it in another mail.
We had quite a few changes we had to make (several hundred man-hours,
about half of which was the POSIX layer and the precise time routines).
No sense trying to simulate fork() -- it stinks on Win32. The Cygwin
and PW32 implementations of fork() are dogs. Smarter folks than us
tried it and failed miserably. Why reinvent a broken wheel? We use
create process and our own startup code. Our version is competitive
with fork() on Linux for spawning tasks and in general the queries run
considerably faster.
Show quoted text
I know Windows very well, but I have thus far remained
ignorant of PostgreSQL
internals.
Import Notes
Resolved by subject fallback
-----Original Message-----
From: mlw [mailto:markw@mohawksoft.com]
Sent: Thursday, May 09, 2002 2:56 PM
To: Dann Corbit
Cc: PostgreSQL-development
Subject: Re: Issues tangential to win32 supportDann Corbit wrote:
Our package avoids Cygwin altogether. We wrote our own
POSIX layer from
scratch, and we junked fork() for CreateProcess() {and
inserted copious:
#ifdef ICKY_WIN32_KLUDGE
/* our code goes here */
#else
/* Standard UNIX code goes here */
#endifOK, what sorts of things did you do in your
ICKY_WIN32_KLUDGE? Were they ever
migrated back into the main tree? Did you simulate fork() or
a stand-alone?I know Windows very well, but I have thus far remained
ignorant of PostgreSQL
internals.It's complete, and it performs like the burning blue
blazes. We have
run the full PostgreSQL test suite to completion with
success. However,
before we release any SQL tool, we have our own test suite
with tens of
thousands of tests to perform. Hence, we won't have a release until
June at the earliest.I think the Japanese one also does not use Cygwin (but I
have not tried
installing it yet).
The japanese site claims cygwin.
This is not correct. (Fortunately, we have someone here who reads and
writes Japanese).
At any rate, it is a complete, native implementation of PostgreSQL
without any need for Cygwin.
Just to be sure, I did a "depends" on each of the binaries and none of
them use Cywin.
So the Japanese site did exactly the same thing that we did.
Here are bitmaps showing the complete dependency trees of both the
Japanese efforts and ours as well:
Us:
ftp://cap.connx.com/pub/chess-engines/new-approach/connx.bmp
Japanese:
ftp://cap.connx.com/pub/chess-engines/new-approach/japanese.bmp
No Cygwin in sight in either case.
Import Notes
Resolved by subject fallback
Dann Corbit wrote:
http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html
Mentions cygwin, am I misunderstanding?
Does not matter, the issue is that you guys said you did it. OK, have you been
able to bring the changed back into the main source tree? (Are you not trying?)
-----Original Message-----
From: mlw [mailto:markw@mohawksoft.com]
Sent: Thursday, May 09, 2002 3:34 PM
To: Dann Corbit
Cc: PostgreSQL-development
Subject: Re: Issues tangential to win32 supportDann Corbit wrote:
http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.htmlMentions cygwin, am I misunderstanding?
Does not matter, the issue is that you guys said you did it.
OK, have you been
able to bring the changed back into the main source tree?
(Are you not trying?)
I am not enrolled in the CVS project, and don't even know how to use it.
We use "Visual Source Safe" here -- really an icky tool but at least
everyone here knows it.
There is some debate here as to whether to keep the changes private or
to turn them back to the project. Not sure how it will turn out.
I am not sure that the project would want them anyway, since the
represent some pretty major surgery and impact the readability of the
code in a quite adverse way.
At any rate, the Japanese version appears to be released. In fact, I
have downloaded the whole project and gave it a spin. It is actually
very nice. If you just need to use something for right now, why not go
with that version?
In any case, there is simply no way possible that anything will ever
escape from here before June at the absolute earliest (full regression
test is company policy).
Import Notes
Resolved by subject fallback
Dann Corbit wrote:
I am not enrolled in the CVS project, and don't even know how to use it.
We use "Visual Source Safe" here -- really an icky tool but at least
everyone here knows it.
Source Safe? Yikes. I haven't used that in a long time.
There is some debate here as to whether to keep the changes private or
to turn them back to the project. Not sure how it will turn out.I am not sure that the project would want them anyway, since the
represent some pretty major surgery and impact the readability of the
code in a quite adverse way.
I hear you on that. I have tons of code that has #ifdef GCC and #ifdef WIN32 in
lots of places.
Obviously you wrap what you can in macros and/or functions, but you can't do
that 100% the time. Some people REALLY hate #ifdef/#endif and view them as a
bad coding practice. Others, like myself, view them as a proper usage of the
language constructs and judicious use of them actually help the developer
understand the code better.
At any rate, the Japanese version appears to be released. In fact, I
have downloaded the whole project and gave it a spin. It is actually
very nice. If you just need to use something for right now, why not go
with that version?
I have no desire for a Windows version for myself, but I see the need for it.
In any case, there is simply no way possible that anything will ever
escape from here before June at the absolute earliest (full regression
test is company policy).
ok
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
Dann Corbit wrote:
http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.htmlMentions cygwin, am I misunderstanding?
Are you talking about following in the page?
----------------------------------------------------------------
* Notice: Based upon the GNU-cygwin, there is a version that works
similar to the Unix-compatible operability. Tanida-san Web site is
supporting this environment in Japanese.
----------------------------------------------------------------
It cleary refers to another work.
--
Tatsuo Ishii