Path to PostgreSQL portabiliy
Do we want a Win32 native version of PostgreSQL?
The only reasons *not* to use Cygwin is licensing, installation hassles, and
maybe stability or performance. Therefore, there is no strong technical reason
to defend its removal, only a philosophical one.
The debates on licensing on this list go on for weeks and people feel
passionately about the subject. It seems odd that no one speaks out about the
GNU requirement of cygwin.
If there is a desire to create a PostgreSQL that is "fork" free, then we should
do it now. If now strong desire exists, then we should make an entry in the FAQ
and move on.
If we want to be "portable" (and this should help us with a threading model
later on) we need to cleanup all of the global variables.
PostgreSQL's postmaster should not touch any global variables that are defined
outside something like a pg_global structure and should not touch any static
variables at all. If postmaster initializes a variable that will get cloned on
a fork(), conceptually it is a shared global variable and belongs in
pg_globals. Going all the way and replacing all globals and statics with a
struct should allow threading with TLS. (Thread Local Storage)
Port lib. Regardless where it comes from, the porting code should be a self
contained library, not a list of objects. On Windows, a .DLL can do some things
easier than an application. Also, having a library allows more flexibility as
to how a port is designed.
We should spec out our port interface. This includes file, semaphores, shared
memory, signals/events, process control, IPC, system resources, etc. This will
grow as we re-port to other environments like Windows.
any comments?
mlw <markw@mohawksoft.com> writes:
Port lib. Regardless where it comes from, the porting code should be a
self contained library, not a list of objects. On Windows, a .DLL can
do some things easier than an application. Also, having a library
allows more flexibility as to how a port is designed.
That may be necessary on Windoze, but on any other platform breaking out
an essential part of the backend as a library strikes me as a dead loss.
You create extra risk of installation mistakes, can't-find-library
startup failures, version mismatch problems, etc, etc --- for zero gain
that I can see.
For comparison you may want to observe the opinion expressed some time
ago by Peter E. that we should fold plpgsql and the other PL's into
the backend, instead of having them as dynamic-linked libraries.
regards, tom lane
Tom Lane wrote:
mlw <markw@mohawksoft.com> writes:
Port lib. Regardless where it comes from, the porting code should be a
self contained library, not a list of objects. On Windows, a .DLL can
do some things easier than an application. Also, having a library
allows more flexibility as to how a port is designed.That may be necessary on Windoze, but on any other platform breaking out
an essential part of the backend as a library strikes me as a dead loss.
You create extra risk of installation mistakes, can't-find-library
startup failures, version mismatch problems, etc, etc --- for zero gain
that I can see.
It does not need, and probably should not be by default, a shared library under
UNIX. A static library is fine. The issue is whether or not it makes sense to
try and design all porting layers the same, or allow the port engineer the
flexibility to create what they need the way they need to do it.
A side note:
The "Windoze" comment says a lot Tom. Believe me, I am currently no fan of
Windows, but there is something to be said about doing a good job supporting
such a popular platform, regardless of our personal opinions. When I was
working at DMN, I had to make sure we could find country music and Brittany
Spears. Distasteful, but certainly something that needed to be done.
IMHO, I think a great PostgreSQL implementation for Win32 is a nail in the
coffin for Windows. If we give them a great database, which runs well under
Windows, for free, MSSQL will now have a serious competitor for the medium to
small marketplace.
Once MSSQL has viable cross-platform competition in this space, one less
requirement for Windows will exist. Right now, if you implement on Windows, you
are most likely going to use MSSQL and be stuck there. With a good Win32
PostgreSQL, an engineer can implement on PostgreSQL for Windows, and easily
move it to a "real" environment for stability.
I see it as an important step.
mlw writes:
[ snip ]
Port lib. Regardless where it comes from, the porting code should be a self
contained library, not a list of objects. On Windows, a .DLL can do some things
easier than an application. Also, having a library allows more flexibility as
to how a port is designed.We should spec out our port interface. This includes file, semaphores, shared
memory, signals/events, process control, IPC, system resources, etc. This will
grow as we re-port to other environments like Windows.
In other words ignore the POSIX capabilities/features of the largely
compatible Unix systems and invent a layer over them to aid porting to
more POSIXly challenged systems (i.e. Windows)...
Seems like the wrong way of doing things - change the majority to aid
the minority! Doesn't the current method of relying on POSIX
compatability layers on Windows make more sense?
Even if such a 'port library' was the way forward, it should be just
using an existing one, i.e. Apache [A]PR. No use replicating all the
effort!
Looking into APR got me back to thinking about a PostgreSQL and mmap -
what's the stance on it? Useable? In the archives someone was looking
into mmap use for WAL, but this hasn't reappeared for 7.3... I'm
thinking about using mmap for COPY FROM...
Lee.
The debates on licensing on this list go on for weeks and people feel
passionately about the subject. It seems odd that no one speaks out about the
GNU requirement of cygwin.
We respect the licensing requirements for that product. And certainly
the licensing requirement for cygwin are no less onerous than for other
products installed on a Windoze platform, or for Windoze itself.
My impression on the licensing requirement is that there is an
inconvenience factor in installing cygwin separately, and a cost factor
in trying to deliver an integrated build.
But I'm actually not certain about *any* onerous requirements for
cygwin, now that I look at it.
<disclaimer>
If we've already covered this, just remind me what Truth is, no need to
go over old territory.
</disclaimer>
Here are some points and questions:
1) cygwin is licensed under GPL. So is GNU/Linux, which provides the
same APIs as cygwin does. Linux does not pollute application licenses,
presumably because Linux itself is not *required* to run the
application; it could be run on another system just as well. That is
true for PostgreSQL's relationship to cygwin on Windows, right? Or has
GNU managed to carefully sort out all GPL vs LGPL issues for
applications and libraries to solve it that way?
2) If (1) does not exempt the PostgreSQL app from GPL polution, then why
not distribute PostgreSQL on Windows using a GPL license? It would be a
license fork, but there is no expectation that the GPL licensed code
would be anything other than a strict copy of the BSD code. And the
latter does not preclude anyone from taking the code and distributing it
under another license, as long as the BSD license is distributed also.
There is no problem distributing the PostgreSQL sources with the cygwin
package, so the requirements for the cygwin license can be fully met. I
think that this would be supported by the rest of the community, as long
as it was not an excuse to discuss GPL vs BSD for the main code base.
3) If (2) is the case, then development could continue under the BSD
license, since developers could use the BSD-original code for their
development work. So there is no risk of "backflow polution".
Thoughts (specific to PostgreSQL on cygwin/windoze, which is not a
happening thing at the moment)?
- Thomas
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of mlw
Sent: Wednesday, May 08, 2002 10:16 AM
To: Tom Lane
Cc: PostgreSQL-development; Jan Wieck; Marc G. Fournier; Dann Corbit
Subject: Re: [HACKERS] Path to PostgreSQL portabiliyIMHO, I think a great PostgreSQL implementation for Win32 is a nail in the
coffin for Windows. If we give them a great database, which runs
well under
Windows, for free, MSSQL will now have a serious competitor for
the medium to
small marketplace.Once MSSQL has viable cross-platform competition in this space, one less
requirement for Windows will exist. Right now, if you implement
on Windows, you
are most likely going to use MSSQL and be stuck there. With a good Win32
PostgreSQL, an engineer can implement on PostgreSQL for Windows,
and easily
move it to a "real" environment for stability.I see it as an important step.
... and for IT staff who do their play-work on the Windows laptops, and to
help compete against MySQL, which has a strong, out-of-the-box Windows
binary, and for people who think it's easier to install and play with things
on Windows first, and ...
It seems like there are lot of open paths discussions, though:
. make cygwin perform better (does it perform badly? is it unstable?)
. make cygwin easier to install
. make windows native (req's semaphore, fork, some shell utils, etc.)
I've installed PG+Cygwin on a few dozen machines, but always to let people
play before the real *nix install. Can anyone speak to _really_ using PG +
Cygwin?
Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant
Joel Burton wrote:
... and for IT staff who do their play-work on the Windows laptops, and to
help compete against MySQL, which has a strong, out-of-the-box Windows
binary, and for people who think it's easier to install and play with things
on Windows first, and ...It seems like there are lot of open paths discussions, though:
. make cygwin perform better (does it perform badly? is it unstable?)
I don't know if a native Win32 binary will perform better, I do know that Linux
running PostgreSQL performs better than Windows running cygwin and PostgreSQL
on the same machine. The extent of what that means is unclear.
. make cygwin easier to install
Or just have a stripped down cygwin runtime.
. make windows native (req's semaphore, fork, some shell utils, etc.)
Hence this whole conversation.
I've installed PG+Cygwin on a few dozen machines, but always to let people
play before the real *nix install. Can anyone speak to _really_ using PG +
Cygwin?
As I think of it, I don't think a cygwin PostgreSQL will *ever* be taken
seriously by the Windows crowd, just as a Wine/CorelDraw wasn't taken seriously
by the Linux crowd.
If we want to support Windows, we should support Windows. Cygwin will not be
accepted by any serious IT team.
Lee Kindness wrote:
mlw writes:
[ snip ]
Port lib. Regardless where it comes from, the porting code should be a self
contained library, not a list of objects. On Windows, a .DLL can do some things
easier than an application. Also, having a library allows more flexibility as
to how a port is designed.We should spec out our port interface. This includes file, semaphores, shared
memory, signals/events, process control, IPC, system resources, etc. This will
grow as we re-port to other environments like Windows.In other words ignore the POSIX capabilities/features of the largely
compatible Unix systems and invent a layer over them to aid porting to
more POSIXly challenged systems (i.e. Windows)...Seems like the wrong way of doing things - change the majority to aid
the minority! Doesn't the current method of relying on POSIX
compatability layers on Windows make more sense?
Depends, do you want the Windows version to actually be used? I have been
writing software for over 20 years now, and sometimes you just have to hold
your nose. It would be nice if we could code what we want, the way we want, in
the language we want, on the platforms we want.
Windows represents a HUGE user base, it also represents a platform for which a
real good native PostgreSQL should do well. There are, to my knowledge, no good
and free databases available for Windows.
PostgreSQL on Windows could be very cool as a serious poster child for why
open-source is the way to go.
Even if such a 'port library' was the way forward, it should be just
using an existing one, i.e. Apache [A]PR. No use replicating all the
effort!
Absolutely, I think Apache's APR is pretty good.
-----Original Message-----
From: markw@snoopy.mohawksoft.com [mailto:markw@snoopy.mohawksoft.com]On
Behalf Of mlw
Sent: Wednesday, May 08, 2002 11:47 AM
To: Joel Burton
Cc: Tom Lane; PostgreSQL-development; Jan Wieck; Marc G. Fournier; Dann
Corbit
Subject: Re: [HACKERS] Path to PostgreSQL portabiliyAs I think of it, I don't think a cygwin PostgreSQL will *ever* be taken
seriously by the Windows crowd, just as a Wine/CorelDraw wasn't
taken seriously
by the Linux crowd.If we want to support Windows, we should support Windows. Cygwin
will not be
accepted by any serious IT team.
Well, I think it's a bit different than Wine, a _huge_ binary trying to
emulate every call of an operating system (and making things more than a bit
slower).
If there is a stripped down, out-of-the-box install that includes cygwin, do
you think that will turn people off? It would be essentially invisible.
There was a native PG (7.0.3, IIRC) floating around on the web, so _someone_
has done this before.
- J.
Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant
Thomas Lockhart <lockhart@fourpalms.org> writes:
2) If (1) does not exempt the PostgreSQL app from GPL polution, then why
not distribute PostgreSQL on Windows using a GPL license?
Given the cygwin licensing terms stated at
http://cygwin.com/licensing.html
it appears to me that we need not open that can of worms (and I'd much
rather not muddy the licensing waters that way, regardless of any
arguments about whether it would hurt or not...)
As near as I can tell, we *could* develop a self-contained installation
package for PG+cygwin without any licensing problem. So that set of
problems could be solved with a reasonable amount of work. I'm still
unclear on whether there are serious technical problems (performance,
stability) with using cygwin.
(Actually, even if there are performance or stability problems, an
easily-installable package would still address the needs of people who
want to "try it out" or "get their feet wet". And maybe that's all we
need to do. We always have said that we recommend a Unix platform for
production-grade PG installations, and IMNSHO that recommendation would
not change one iota if there were a native rather than cygwin-based
Windows port. So I'm unconvinced that we have a problem to solve
anyway...)
regards, tom lane
Joel Burton wrote:
-----Original Message-----
From: markw@snoopy.mohawksoft.com [mailto:markw@snoopy.mohawksoft.com]On
Behalf Of mlw
Sent: Wednesday, May 08, 2002 11:47 AM
To: Joel Burton
Cc: Tom Lane; PostgreSQL-development; Jan Wieck; Marc G. Fournier; Dann
Corbit
Subject: Re: [HACKERS] Path to PostgreSQL portabiliyAs I think of it, I don't think a cygwin PostgreSQL will *ever* be taken
seriously by the Windows crowd, just as a Wine/CorelDraw wasn't
taken seriously
by the Linux crowd.If we want to support Windows, we should support Windows. Cygwin
will not be
accepted by any serious IT team.Well, I think it's a bit different than Wine, a _huge_ binary trying to
emulate every call of an operating system (and making things more than a bit
slower).If there is a stripped down, out-of-the-box install that includes cygwin, do
you think that will turn people off? It would be essentially invisible.
I was thinking about this earlier, one problem with cygwin is it doesn't act
like a Windows program, it requires its own file layout.
Cygwin's purpose in life to to allow basically UNIX centric people to be
comfortable on Windows. It, by no means, is anything that a Windows centric
person wants to deal with, or would deal with if there were an alternative.
...
As near as I can tell, we *could* develop a self-contained installation
package for PG+cygwin without any licensing problem.
Right. That was my opinion also. But istm that however the discussion
settles out, there is a path to success.
- Thomas
Thomas Lockhart wrote:
...
As near as I can tell, we *could* develop a self-contained installation
package for PG+cygwin without any licensing problem.Right. That was my opinion also. But istm that however the discussion
settles out, there is a path to success.
These last couple days have really started me thinking about Windows again. I
developed Windows software for over a decade, geez much longer than that, I
wrote my first Windows program using the Windows 1.03 SDK. (I am in a 12 step
program now, but you guys are causing a relapse!)
Listen, here is purely my opinion on the matter, I am speaking from my
experience as a Windows user, developer, and author (Tricks of the Windows 3.1
Masters).
It is useless to spend serious time on a cygwin version. Yea, it is cool and
all, but it won't be used. From the eyes of a Windows user cygwin is a hack and
a mess. An IT guy that only knows Windows will never use it, and if presented
with a program that forces a UNIX like directory tree on their hard drive and
UNIX like tools to manage it, they will delete the program and curse the time
spent installing it.
Performance may also be an issue, I don't know for sure, but it is suspected.
The cygwin fork troubles me as well. It may work, but I would not call it a
"production" technique, how about you? Would you bet your business on cygwin
and a hacked fork()?
No matter what steps you take, cygwin will not be seen by Windows users as
anything but a sloppy/messy/horrible hack. It is a fact of life. You are
welcome to disagree, but I assure you it is true.
From a usefulness perspective, a cygwin version of PostgreSQL will be nothing
more than a proof of concept, a test bed, or a demo. It will never be used as a
serious database. How much work does that warrant?
On Wed, 8 May 2002, Tom Lane wrote:
Thomas Lockhart <lockhart@fourpalms.org> writes:
2) If (1) does not exempt the PostgreSQL app from GPL polution, then why
not distribute PostgreSQL on Windows using a GPL license?Given the cygwin licensing terms stated at
http://cygwin.com/licensing.html
it appears to me that we need not open that can of worms (and I'd much
rather not muddy the licensing waters that way, regardless of any
arguments about whether it would hurt or not...)As near as I can tell, we *could* develop a self-contained installation
package for PG+cygwin without any licensing problem. So that set of
problems could be solved with a reasonable amount of work. I'm still
unclear on whether there are serious technical problems (performance,
stability) with using cygwin.
The last time I tried to play with it, any sort of load tended to blow
away the whole IPC side of things ... it was stable to "play with", but
for any *serious* work ... this may have changed though, as it has been
awhile since I played with it last ...
On Wednesday 08 May 2002 11:37 am, Thomas Lockhart wrote:
1) cygwin is licensed under GPL. So is GNU/Linux, which provides the
same APIs as cygwin does. Linux does not pollute application licenses,
presumably because Linux itself is not *required* to run the
The Linux kernel is not under a pure GPL.
COPYING in the kernel source says this, prepended to the GPL:
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
Linus Torvalds
--------------------------------------------------------------------------
Does cygwin make the same statement?
2) If (1) does not exempt the PostgreSQL app from GPL polution, then why
not distribute PostgreSQL on Windows using a GPL license?
[snip]
3) If (2) is the case, then development could continue under the BSD
license, since developers could use the BSD-original code for their
development work. So there is no risk of "backflow polution".
Can PostgreSQL, Inc be the GPL distributor for these purposes, being a
separate entity from the PostgreSQL Global Development Group?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
mlw wrote:
No matter what steps you take, cygwin will not be seen by Windows users as
anything but a sloppy/messy/horrible hack. It is a fact of life. You are
welcome to disagree, but I assure you it is true.
Just to clarify here: is it confirmed that having the complete cygwin
distribution is a necessary condition to having a running PostgreSQL on
windows? Is it not possible that, having built postgresql with the full
cygwin, it would be possible to make a nice clean setup.exe package
which bundles the postgresql executables, the required cygwin dlls and
other niceties into an easy install package? Given that, I do not think
your putative windows user would care at all about what was going on
under the covers. As long as the install was clean, there were utilities
(pgadmin?) to start working with the database right away, and things
"just worked", the ugliness (or exquisite symmetry... I am not an
expert) of the fork() implementation really would not be an issue :)
Of course, an imaginary beautiful packaging regime hinges on the
possibility of bundling the cygwin api libraries cleanly without
bundling all the rest of the cygwin scruft (unix directory heirarchy,
etc etc). Anyone have any light to shed on cygwin's "packagability"?
P.
Paul Ramsey wrote:
mlw wrote:
No matter what steps you take, cygwin will not be seen by Windows users as
anything but a sloppy/messy/horrible hack. It is a fact of life. You are
welcome to disagree, but I assure you it is true.Just to clarify here: is it confirmed that having the complete cygwin
distribution is a necessary condition to having a running PostgreSQL on
windows? Is it not possible that, having built postgresql with the full
cygwin, it would be possible to make a nice clean setup.exe package
which bundles the postgresql executables, the required cygwin dlls and
other niceties into an easy install package? Given that, I do not think
your putative windows user would care at all about what was going on
under the covers. As long as the install was clean, there were utilities
(pgadmin?) to start working with the database right away, and things
"just worked", the ugliness (or exquisite symmetry... I am not an
expert) of the fork() implementation really would not be an issue :)
Windows users expect to have C:\my programs\postgres as the install location. A
person who has used or looked at MSSQL would expect to deal with the real file
system. The cygwin environment shields the UNIX program from Windows, the
Windows user would expect the program to deal with the system as is.
The Windows user that would install PostgreSQL would expect it to be a real
windows program, but would be savvy enough (and prejudiced enough) to know if
it weren't.
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Paul Ramsey
Sent: Wednesday, May 08, 2002 3:54 PM
To: mlw
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Path to PostgreSQL portabiliymlw wrote:
No matter what steps you take, cygwin will not be seen by
Windows users as
anything but a sloppy/messy/horrible hack. It is a fact of life. You are
welcome to disagree, but I assure you it is true.Just to clarify here: is it confirmed that having the complete cygwin
distribution is a necessary condition to having a running PostgreSQL on
windows? Is it not possible that, having built postgresql with the full
cygwin, it would be possible to make a nice clean setup.exe package
which bundles the postgresql executables, the required cygwin dlls and
other niceties into an easy install package? Given that, I do not think
your putative windows user would care at all about what was going on
under the covers. As long as the install was clean, there were utilities
(pgadmin?) to start working with the database right away, and things
"just worked", the ugliness (or exquisite symmetry... I am not an
expert) of the fork() implementation really would not be an issue :)Of course, an imaginary beautiful packaging regime hinges on the
possibility of bundling the cygwin api libraries cleanly without
bundling all the rest of the cygwin scruft (unix directory heirarchy,
etc etc). Anyone have any light to shed on cygwin's "packagability"?
Certainly, we don't need all of cygwin (eg bison, gcc, perl, et al). We'd
need the dll, sh, rm, and few other things. I'm not sure if it would need to
be in the standard cygwin file structure; I know that you can reconfigure
this when you use cygwin (I used to). In any event, instead of having to
have a novice pick & guess which of >100 packages they need, we could put
together the 5 or 6 they need.
I'm not sure I agree entirely with mlw: some Windows admins will be afraid
of cygwin, but, I'll bet more than a few won't even notice that its being
used (especially if we can change the dir names, provide windows shortcuts
to the commands like initdb, create database, pg_ctl, etc., which would be
trivial to do).
Still unanswered is real data on whether cygwin would be good for serious
production use by real people. However, for the test/play/try-out model, I
think cygwin would be a fine solution, and wouldn't (shouldn't?) require too
much work.
- J.
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of mlw
Sent: Wednesday, May 08, 2002 4:12 PM
To: Paul Ramsey
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Path to PostgreSQL portabiliyWindows users expect to have C:\my programs\postgres as the
install location. A
person who has used or looked at MSSQL would expect to deal with
the real file
system. The cygwin environment shields the UNIX program from Windows, the
Windows user would expect the program to deal with the system as is.The Windows user that would install PostgreSQL would expect it to
be a real
windows program, but would be savvy enough (and prejudiced
enough) to know if
it weren't.
It's not the nicest thing, but the root for the mini-cygwin/PG could be
c:\program files\postgresql. Then PG itself could be something like
c:\program files\postgresql\bin. Java, for instance, comes packed in
c:\program files\javasoft\_version_number_\bin.
In any event, for people that want to play around, test it out, do some PG
work on their laptop at night, etc., I don't think they'd really care that
it's not a "real" windows program. I'm a dedicated unix weenie, and I have
PG + cygwin on the windows partition of my machines. It's very convenient at
times.
Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant
If you have a Win32 workstation...
Look here:
http://sources.redhat.com/cygwin/
Then click on the thing that says "Install Now" (Looks like a black "C"
with a green tongue).
after a small boatload of clicks, you will see a Window labeled "Cygwin
Setup".
Under +All
you will find...
+Admin
+Archive
+Base
+DatabaseClick on the plus sign next to the Database category.
You will see:
7.2.1-1 [options] [Bin] [Src] [Package] posgresql: PostgreSQL
Data Base Management System
In other words, they already have an automated installation procedure
for PostgreSQL if you are using Cygwin.
Import Notes
Resolved by subject fallback
I think that cygwin is just a hack that allows you to distribute a software
developped for UNIX under Windows. I see the point for using it in a company
that wants to have a bigger market and doesn't really care about the speed
of its application (because cygwin slows down your application quite a bit).
But an open source project should try to have the best implementation, most
of all the main site. If you want a port to Windows with cygnus, let other
sattelite projects do it as they already exist, and add links to these
projects to the home page.
May be its time again to dig up this old subject of thread support. Even the
Unix implementation could have a mixed multi-process multi-thread
architecture. The postmaster could start a certain number of processes each
process beeing able to be multi-threaded if the platform supports it. If you
really don't want of threads it is possible to implement a event
demultiplexer loop and each process can benefit of any delay to do something
else. Then you benefit of idle time in the connexion and even after further
optimization you can benefit of idle time during I/O.
One good start point is the GNU Pth library that implements cooperative
threads. It's a good start because it is supported on many platforms and
it's easier to implement thread support step by step: cooperative in an
event demultiplexing way and then preemptive. Pth has a Posix layer to keep
all things more standard.
Regards,
Nicolas
----- Original Message -----
From: "Paul Ramsey" <pramsey@refractions.net>
To: "mlw" <markw@mohawksoft.com>
Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Sent: Thursday, May 09, 2002 5:53 AM
Subject: Re: [HACKERS] Path to PostgreSQL portabiliy
mlw wrote:
No matter what steps you take, cygwin will not be seen by Windows users
as
Show quoted text
anything but a sloppy/messy/horrible hack. It is a fact of life. You are
welcome to disagree, but I assure you it is true.Just to clarify here: is it confirmed that having the complete cygwin
distribution is a necessary condition to having a running PostgreSQL on
windows? Is it not possible that, having built postgresql with the full
cygwin, it would be possible to make a nice clean setup.exe package
which bundles the postgresql executables, the required cygwin dlls and
other niceties into an easy install package? Given that, I do not think
your putative windows user would care at all about what was going on
under the covers. As long as the install was clean, there were utilities
(pgadmin?) to start working with the database right away, and things
"just worked", the ugliness (or exquisite symmetry... I am not an
expert) of the fork() implementation really would not be an issue :)Of course, an imaginary beautiful packaging regime hinges on the
possibility of bundling the cygwin api libraries cleanly without
bundling all the rest of the cygwin scruft (unix directory heirarchy,
etc etc). Anyone have any light to shed on cygwin's "packagability"?P.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Dann Corbit
Sent: Wednesday, May 08, 2002 7:31 PM
To: PostgreSQL-development
Subject: Re: [HACKERS] Path to PostgreSQL portabiliyIf you have a Win32 workstation...
Look here:
http://sources.redhat.com/cygwin/Then click on the thing that says "Install Now" (Looks like a black "C"
with a green tongue).after a small boatload of clicks, you will see a Window labeled "Cygwin Setup". Under +All you will find... +Admin +Archive +Base +DatabaseClick on the plus sign next to the Database category.
You will see:
7.2.1-1 [options] [Bin] [Src] [Package] posgresql: PostgreSQL
Data Base Management SystemIn other words, they already have an automated installation procedure
for PostgreSQL if you are using Cygwin.
Yes, but you need to choose other packages in addition to PG to get it to
work, and which ones you need to choose aren't obvious. I think, at least,
we could provide some documentation on a straightforward PG cygwin install.
In other words, they already have an automated installation procedure
for PostgreSQL if you are using Cygwin.Yes, but you need to choose other packages in addition to PG to get it to
work, and which ones you need to choose aren't obvious. I think, at least,
we could provide some documentation on a straightforward PG
cygwin install.
I think a full, proper native version of Postgres for windows that can be
compiled and distributed as a binary with installer is essential. Just look
at how many people use MySQL for windows.
We should just rip out our own IPC code and replace it with the APR...
Chris
Who really is your target "market" on the windows platform? Microsoft
Access users (many)? MySQL users(insignificant?)? MSSQL (many)?
Assuming that the postgresql team isn't getting lots of money or resources
to do it. I don't see why you would want to invest a lot to support windows
from a long term point of view. Windows can be a costly platform to support.
Because if you become a serious threat, Microsoft can rip the rug from
beneath you any chance they get. Also Microsoft WILL always change their
APIs. They're not stupid. If Microsoft freezes their APIs they will end up
like "yet another BIOS manufacturer", and bye bye profit margins. Microsoft
will strive to keep it a proprietary AND changing API.
Windows is rather different operationally. Automating vacuum etc on windows
is going to be different. Starting postgresql as a service is going to be
different as well. Same for uninstalling. So support requests are going to
be different.
If your target market is consumer - Windows consumer users also have
different expectations. Most will want nicer GUIs (those that don't care
won't mind running Postgresql elsewhere).
BTW if your target market is a bit higher end - typically those that "must
use" windows also "must use" MSSQL/Oracle/etc. You will thus have to build
brand recognition for Postgresql on Windows.
All this will cost you.
That said, is it easier to support only Windows NT/2000 and forget about
Win9x? The bigger dbs don't support win9x either (how does Oracle/DB2
support NT? They seem to work ok). Leave MySQL to the Win9x people ;). BTW
does MySQL really perform OK on Win9x?
Forget the Cygwin approach. Is there really a market for that? Unless
things have got a lot easier, installing Cygwin is like installing a new
O/S just to install your app. And installing and learning a new system has
got to be one of the major barriers, otherwise people will either buy a new
USD500 1.5+ GHz pc or use VMware+BSD/Linux+Postgresql ;).
Cheerio,
Link.
At 11:53 AM 5/8/02 -0400, mlw wrote:
Show quoted text
writing software for over 20 years now, and sometimes you just have to hold
your nose. It would be nice if we could code what we want, the way we want, in
the language we want, on the platforms we want.Windows represents a HUGE user base, it also represents a platform for which a
real good native PostgreSQL should do well. There are, to my knowledge, no
good
and free databases available for Windows.PostgreSQL on Windows could be very cool as a serious poster child for why
open-source is the way to go.
-----Original Message-----
From: Dann Corbit [mailto:DCorbit@connx.com]
Sent: 09 May 2002 00:31
To: PostgreSQL-development
Subject: Re: Path to PostgreSQL portabiliyIf you have a Win32 workstation...
Look here:
http://sources.redhat.com/cygwin/Then click on the thing that says "Install Now" (Looks like a
black "C" with a green tongue).after a small boatload of clicks, you will see a Window labeled "Cygwin Setup". Under +All you will find... +Admin +Archive +Base +DatabaseClick on the plus sign next to the Database category.
You will see:
7.2.1-1 [options] [Bin] [Src] [Package] posgresql:
PostgreSQL Data Base Management SystemIn other words, they already have an automated installation
procedure for PostgreSQL if you are using Cygwin.
The last time I tried that (coupla months ago) it listed the versions of
the packages in reverse order, so I spent about 15 very tedious minutes
making sure that I have the latest version of all the packages I wanted
selected.
Then I spent an hour or 2 battling with ntsec and initdb on my laptop
(logged onto, but disconnected from the domain). After that I gave up
and went back to my very old release that works fine.
The point I'm trying to make is that if I, as a not inexperienced
sysadmin of both Windows and Unix systems (not to mention PostgreSQL
which I like to think I'm fairly familiar with) has this trouble, what
impression is that going to give the first time user, who's probably
going to go elsewhere at the first sign of trouble?
Regards, Dave.
Import Notes
Resolved by subject fallback
Le Jeudi 9 Mai 2002 01:30, Dann Corbit a écrit :
In other words, they already have an automated installation procedure
for PostgreSQL if you are using Cygwin.
Cygwin installer does not handle package dependencies. Therefore:
1) users install all packages at once.
2) upgrading becomes a mess .
3) sofware may conflict. Example : Cygwin Perl and native Perl, Cygwin Apache
and native Apache.
IMHO the problem stems from the lack of package installers the Windows world.
Here is the proposed plan, which boils down to port Debian to Cygwin/Windows:
1) Description of W32/Debian porting
- Port Debian dpkg to native Windows and compile it using mingw. This task has
nearly been accomplished on http://debian-cygwin.sourceforge.net/bootstrap/.
dpkg is a very powerfull package system comparable to RPM on Linux. I don't
know if it is possible to compile dpkg natively under Windows using mingw.
- Create W32/Debian packages providing mingw core executables and libraries.
- Compile Cygwin.dll using mingw. This will enable the creation of a first
W32/Debian Cygwin.dll package. This should be possible using MSYS-1.0.7 and
MinGW-1.1. Again, Cygwin installer is messy, we should get rid of it.
- Create W32/Debian packages providing Cygwin core packages.
- At that point, we shoul be able to have our own Cygwin installer with
dependency checking. There we go:
This will allow to create further W32/Debian packages and tell wether they
depend on Cygwin or not. For example, we may offer Perl with depency to
Cygwin and another one with no depency (compiled with mingw). Another
example is Apache : users may be interested in compiling the Cygwin version
of Apache, but they might as well simply need to install the Windows native
binary version.
Also there are a bunch of Windows only programs. Example Dev-C++ or
OpenOffice. We should also package them.
- Create W32/Debian packages for GUI environnement (Xfree / qt2 / KDE2 /
Gnome). Porting has already been accomplised on Cygwin. Even KDE3 is on the
way. See http://kde-cygwin.sourceforge.net/.
User will be able to open a KDE window and execute KDE applications without
hastle. This will allow us to offer popular developement environments (ex:
KDevelop).
2) GUI installer
W32/Debian installation should be performed within a single GUI. The
installation program will give access to all W32/Debian packages at once.
Packages will be available on Debian mirrors.
Basically, there will be two kinds of packages :
- native Windows software (native PHP + apache, native python, native Dev-C++,
native OpenOffice1.0) with no depency to Cygwin.
- Unix and Linux ports with Cygwin dependency (ex : PostgreSQL at first).
All of them will be available within a SINGLE INSTALLER.
So to me, the question is not "How to we port PostgreSQL to Windows" but
rather "How do we package all important software needed", including Cygwin
dependant software and Windows native software.
If we could provide such an installer, this could well be the end of Microsoft
hegemony. Microsoft is a dangerous company violating Human Rights.
Don't spend too much time on porting PostgreSQL to native Windows. This can be
done in two months. The amount of work needed to create a minimal W32/Debian
distribution with an on-line installer is very little for a community like
ours. This would change the history of Windows computing.
Cheers,
Jean-Michel POURE
On Wed, 8 May 2002, Lamar Owen wrote:
3) If (2) is the case, then development could continue under the BSD
license, since developers could use the BSD-original code for their
development work. So there is no risk of "backflow polution".Can PostgreSQL, Inc be the GPL distributor for these purposes, being a
separate entity from the PostgreSQL Global Development Group?
Ummmm ... no? We tend to be anti-GPL over here, since its anti-business
... gborg would be a good place for any of this ...
"Marc G. Fournier" <scrappy@hub.org> writes:
Ummmm ... no? We tend to be anti-GPL over here, since its anti-business
Let's not use loaded terms here.
-Doug
Import Notes
Reply to msg id not found: MarcG.FourniersmessageofThu9May2002085119-0300ADT
Paul Ramsey wrote:
mlw wrote:
No matter what steps you take, cygwin will not be seen by Windows users as
anything but a sloppy/messy/horrible hack. It is a fact of life. You are
welcome to disagree, but I assure you it is true.Just to clarify here: is it confirmed that having the complete cygwin
distribution is a necessary condition to having a running PostgreSQL on
windows? Is it not possible that, having built postgresql with the full
cygwin, it would be possible to make a nice clean setup.exe package
Well, PostgreSQL goes as far as using system(3) to do "cp -r"
and stuff. Dunno what you call it, but I'd say it's making
assumptions that one shouldn't make :-)
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
Joel Burton wrote:
Certainly, we don't need all of cygwin (eg bison, gcc, perl, et al). We'd
need the dll, sh, rm, and few other things. I'm not sure if it would need to
be in the standard cygwin file structure; I know that you can reconfigure
this when you use cygwin (I used to). In any event, instead of having to
have a novice pick & guess which of >100 packages they need, we could put
together the 5 or 6 they need.
Oh, BTW, had anyone luck with loading of user defined C
functions or the PL handlers under CygWin? I remember having
had trouble with that. When the C function uses global
variables in the backend, things get a bit messy.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
From: "Jan Wieck" <janwieck@yahoo.com>
Joel Burton wrote:
Certainly, we don't need all of cygwin (eg bison, gcc, perl, et al).
We'd
need the dll, sh, rm, and few other things. I'm not sure if it would
need to
be in the standard cygwin file structure; I know that you can
reconfigure
this when you use cygwin (I used to). In any event, instead of having to
have a novice pick & guess which of >100 packages they need, we could
put
together the 5 or 6 they need.
Oh, BTW, had anyone luck with loading of user defined C
functions or the PL handlers under CygWin? I remember having
had trouble with that. When the C function uses global
variables in the backend, things get a bit messy.
I have a 7.1.3 install with cygwin and I'm using pl/pgsql and a custom
type (with accessor written in a C dll). It never cause me any problem.
My custom dll is not using global var in the backend though.
cyril
On Thursday 09 May 2002 07:51 am, Marc G. Fournier wrote:
On Wed, 8 May 2002, Lamar Owen wrote:
3) If (2) is the case, then development could continue under the BSD
license, since developers could use the BSD-original code for their
development work. So there is no risk of "backflow polution".
Can PostgreSQL, Inc be the GPL distributor for these purposes, being a
separate entity from the PostgreSQL Global Development Group?
Ummmm ... no? We tend to be anti-GPL over here, since its anti-business
... gborg would be a good place for any of this ...
I can see my feeble attempt at humor fell flat. Sorry.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Hi,
Win32 & threads support are both going to be a lot of work and maybe
we'll need in the future one or both - is there any chance Postgres
developers look at the Apache experience? Briefly, Apache 2 had the some
problems as are discussed here (need to support Win, problems with Win32
fork, questionable cygwin etc) and they decided to solve it once and for
all with their Apache Portable Runtime and Multi-Processing Modules. APR
was already mentioned here - now how about MPMs?
- Robert
PS Relevant links:
http://httpd.apache.org/docs-2.0/mpm.html
http://httpd.apache.org/docs-2.0/new_features_2_0.html
PS2 It took them some three years to release Apache 2 so it's probable
not that easy - but you knew that already.
PS3 And when talking about Win32 Postgres uses, don't forget there might
be a large number of people who would use Posgtres embeded in accounting
and many other packages - it can be single user Win98, but it might
still need decent SQL backend (subqueries, user functions for all kind
of CDROM catalogs etc). So when doing major rearchitecture of Postgres,
it might be usefull to plan for a bit of modularity maybe like in
Mozilla when you can drop UI and use just the layout engine or just the
JavaScript etc.
Robert wrote:
Hi,
Win32 & threads support are both going to be a lot of work and maybe
we'll need in the future one or both - is there any chance Postgres
developers look at the Apache experience? Briefly, Apache 2 had the some
problems as are discussed here (need to support Win, problems with Win32
fork, questionable cygwin etc) and they decided to solve it once and for
all with their Apache Portable Runtime and Multi-Processing Modules. APR
was already mentioned here - now how about MPMs?
I am starting to come to the conclusion that the PostgreSQL group is satisfied
with cygwin, and the will to create a native Win32 version does not exist
outside of a few organizations that are paying developers to create one.
Without some buy-in from the core team, I'm not sure I am willing to spend my
time on it. If someone would be willing to fund the 100 or so man-hours
required to do it, then that would be a different story.
Le Vendredi 10 Mai 2002 13:13, mlw a écrit :
I am starting to come to the conclusion that the PostgreSQL group is
satisfied with cygwin, and the will to create a native Win32 version does
not exist outside of a few organizations that are paying developers to
create one.
The more important is get a Windows version on the way. pgAdmin2, PostgreSQL
Windows GUI, will soon be included in the Dev-C++ development environment, as
per discussion with Colin Laplace.
Native tools for Windows can have a huge success. Dev-C++ had 1.200.000 hits
over the last years.
Without some buy-in from the core team, I'm not sure I am willing to spend
my time on it. If someone would be willing to fund the 100 or so man-hours
required to do it, then that would be a different story.
I suggest we focuss on providing a minimal PostgreSQL + Cygwin layer at first.
This will give you the required user base to transform PostgreSQL into a
multi-platform RDBMS.
If we add together direct downloads on http://www.postgresql.org and from
partner sites (Dec-C++ on http://www.bloodshed.net), we could well reach the
number of 1.000.000 downloads a year under the Windows platform.
Cheers,
Jean-Michel
Jean-Michel POURE wrote:
Without some buy-in from the core team, I'm not sure I am willing to spend
my time on it. If someone would be willing to fund the 100 or so man-hours
required to do it, then that would be a different story.I suggest we focuss on providing a minimal PostgreSQL + Cygwin layer at first.
This will give you the required user base to transform PostgreSQL into a
multi-platform RDBMS.
Sorry, I'm not interested in a cygwin version of PostgreSQL. I think it will do
more harm than good. If we make it something that people want to try, and then
they TRY it, they will find that is sucks, then we lose. It is very hard to
remove the bad taste in ones mouth of a poor product. Think Yugo.
I have no patience with designed to fail projects, certainly not with my time.
PostgreSQL+cygwin is a loser. If I am going to invest my time and effort, I
want it to be great.
Put it this way. The run of the mill Windows developer will be using MSDN. With
MSDN comes MSSQL. To the developer, it is largely free to setup MSSQL to do
development work.
OK, a conscientious developer will explore options. They will install various
systems and try them. Given a cygwin+PostgreSQL system, MSSQL, MySQL, Oracle,
DB2, etc. MSSQL will win. MSSQL will win over Oracle for cost and ease of
setup. DB2 will lose, similarly to Oracle. MySQL will lose because it sucks.
PostgreSQL+cygwin will lose because it will also suck.
The idea is to "sway" Microsoft developers to open source, not give them
ammunition of why they think it sucks.
Le Vendredi 10 Mai 2002 14:06, mlw a écrit :
Sorry, I'm not interested in a cygwin version of PostgreSQL. I think it
will do more harm than good. If we make it something that people want to
try, and then they TRY it, they will find that is sucks, then we lose. It
is very hard to remove the bad taste in ones mouth of a poor product. Think
Yugo.
Cygwin is very stable. Its community is relatively small but very actuve. We
could well provide a unique installer to "hide" Cygwin from the user. This
can be done compiling Cygwin.dll in a separate user space, as per discussion
with Dave Page.
I have no patience with designed to fail projects, certainly not with my
time. PostgreSQL+cygwin is a loser. If I am going to invest my time and
effort, I want it to be great.
I agree a native Windows PostgreSQL would be better.
OK, a conscientious developer will explore options. They will install
various systems and try them. Given a cygwin+PostgreSQL system, MSSQL,
MySQL, Oracle, DB2, etc. MSSQL will win. MSSQL will win over Oracle for
cost and ease of setup. DB2 will lose, similarly to Oracle. MySQL will lose
because it sucks. PostgreSQL+cygwin will lose because it will also suck.
MySQL under Windows is based on Cygwin.
MySQL sucks and has a 'huge" success.
So let's do it in three moves :
- first move : gain a large audience providing a stable release of Cygwin +
PostgreSQL. This could be done within days ... not weeks. This will be much
better than MySQL.
- second move : release a bundle of pgAdmin2 + PostgreSQL on
http://www.postgresql.org, Bloodshed and other sites.
- third move : based on 1.000.000 downloads and 100.000 users, feed the
community with more developpers, more ideas and more Windows native
source-code. So you wron't say "I am alone".
"Rome ne s'est pas faite en une nuit".
Cheers,
Jean-michel
Hi all
Do u know that there are huge ammount of PRODUCTION(!!!) Windows NT
servers runnini apache , php and mysql? Just because the administrators
are lame, or because some companies cant afford more than one server,
and before they decided to use Windows NT (because they did not knew
about UNIX/Linux/FreeBSD). This is the reality.
One more thing - development for PgSQL is quite dificult just because it
does not runs on Windows 9X. There are huge ammount of development
servers running Win 9X, IIS, PHP and MySQL.
A Windows port for postgres will be great. There were before a postgres
installation for wndows but it does not worked properly.
Is not important HOW stable will Windows version work. For example MySQL
for Win is quite UNSTABLE too. The more important is to be VERY EASY to
be installed, thats all.
Nikolay.
-----------------------------------------------------------
The Reboots are for hardware upgrades,
Found more here: http://www.nmmm.nu
Nikolay Mihaylov nmmm@nmmm.nu
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Jean-Michel
POURE
Sent: Friday, May 10, 2002 3:37 PM
To: mlw
Cc: Robert; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pgAdmin2 to be included in Dev-C++
Le Vendredi 10 Mai 2002 14:06, mlw a écrit :
Sorry, I'm not interested in a cygwin version of PostgreSQL. I think
it will do more harm than good. If we make it something that people
want to try, and then they TRY it, they will find that is sucks, then
we lose. It is very hard to remove the bad taste in ones mouth of a
poor product. Think Yugo.
Cygwin is very stable. Its community is relatively small but very
actuve. We
could well provide a unique installer to "hide" Cygwin from the user.
This
can be done compiling Cygwin.dll in a separate user space, as per
discussion
with Dave Page.
I have no patience with designed to fail projects, certainly not with
my time. PostgreSQL+cygwin is a loser. If I am going to invest my time
and effort, I want it to be great.
I agree a native Windows PostgreSQL would be better.
OK, a conscientious developer will explore options. They will install
various systems and try them. Given a cygwin+PostgreSQL system, MSSQL,
MySQL, Oracle, DB2, etc. MSSQL will win. MSSQL will win over Oracle
for cost and ease of setup. DB2 will lose, similarly to Oracle. MySQL
will lose because it sucks. PostgreSQL+cygwin will lose because it
will also suck.
MySQL under Windows is based on Cygwin.
MySQL sucks and has a 'huge" success.
So let's do it in three moves :
- first move : gain a large audience providing a stable release of
Cygwin +
PostgreSQL. This could be done within days ... not weeks. This will be
much
better than MySQL.
- second move : release a bundle of pgAdmin2 + PostgreSQL on
http://www.postgresql.org, Bloodshed and other sites.
- third move : based on 1.000.000 downloads and 100.000 users, feed the
community with more developpers, more ideas and more Windows native
source-code. So you wron't say "I am alone".
"Rome ne s'est pas faite en une nuit".
Cheers,
Jean-michel
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Jean-Michel POURE wrote:
Le Vendredi 10 Mai 2002 14:06, mlw a �crit :
Sorry, I'm not interested in a cygwin version of PostgreSQL. I think it
will do more harm than good. If we make it something that people want to
try, and then they TRY it, they will find that is sucks, then we lose. It
is very hard to remove the bad taste in ones mouth of a poor product. Think
Yugo.Cygwin is very stable. Its community is relatively small but very actuve. We
could well provide a unique installer to "hide" Cygwin from the user. This
can be done compiling Cygwin.dll in a separate user space, as per discussion
with Dave Page.
Here are the 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 be allocated when the parent process data
is copied.
As a product manager, I would not commit to using a cygwin application in
production. Do you know of any long-uptime systems using cygwin? PostgreSQL
would need to run for months. I would view it as a risk.
Lastly, a Windows program is expected to be a Windows program. Native paths
need to be used, like C:\My Database, D:\My Postgres, or something like that.
Native tools must be used to manage it.
I have no patience with designed to fail projects, certainly not with my
MySQL under Windows is based on Cygwin.
MySQL sucks and has a 'huge" success.
Define "Success"
So let's do it in three moves :
- first move : gain a large audience providing a stable release of Cygwin +
PostgreSQL. This could be done within days ... not weeks. This will be much
better than MySQL.
No interest in cygwin, sorry.
Hi everyone,
Jean-Michel POURE wrote:
<snip>
- second move : release a bundle of pgAdmin2 + PostgreSQL on
http://www.postgresql.org, Bloodshed and other sites.
Don't know if it's useful to know, but a PostgreSQL project got setup on
Sourceforge recently (no CVS), pretty much just so PostgreSQL could be
included in the "Database Foundry" on the Sourceforge site. :)
http://www.sf.net/projects/pgsql
And then I started a new contract and haven't had time to do anything
with it (oh well).
Regards and best wishes,
Justin Clift
<snip>
"Rome ne s'est pas faite en une nuit".
Cheers,
Jean-michel---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Dear Mark,
Agreed except for paths (see below). But now that we agree, why not move to
Windows in three steps:
1) Release a minimal Cygwin + PostgreSQL installer,
2) Have 100.000 downloads or more Windows developpers,
3) Work as a team on a Windows port.
By the way : Cygwin accepts both Windows AND Unix paths depending on
installation options. Cygwin is able to understand C:\program
files\postgresql\var\lib\pgsql, /cygdrive/../var/lib/pgsql or simply
/var/lib/pgsql.
Cheers,
Jean-Michel
Show quoted text
Here are the 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 be allocated when the
parent process data is copied.
As a product manager, I would not commit to using a cygwin application in
production. Do you know of any long-uptime systems using cygwin? PostgreSQL
would need to run for months. I would view it as a risk.
Lastly, a Windows program is expected to be a Windows program. Native paths
need to be used, like C:\My Database, D:\My Postgres, or something like
that. Native tools must be used to manage it.
Jean-Michel POURE wrote:
Dear Mark,
Agreed except for paths (see below). But now that we agree, why not move to
Windows in three steps:
1) Release a minimal Cygwin + PostgreSQL installer,
2) Have 100.000 downloads or more Windows developpers,
3) Work as a team on a Windows port.By the way : Cygwin accepts both Windows AND Unix paths depending on
installation options. Cygwin is able to understand C:\program
files\postgresql\var\lib\pgsql, /cygdrive/../var/lib/pgsql or simply
/var/lib/pgsql.
The point you are missing is that a cygwin version of postgres is unacceptable.
Doing an installer BEFORE commiting to making the system excellent is putting
the cart before the horse.
The LAST thing we want is 100,000+ Windows users downloading PostgreSQL and
getting a cygwin version.
The first time it doesn't work because of anti-virus software, they'll call it
junk. When they test performance and see that it sucks, they'll remove the
software.
Le Vendredi 10 Mai 2002 15:33, mlw a écrit :
The first time it doesn't work because of anti-virus software, they'll call
it junk. When they test performance and see that it sucks, they'll remove
the software.
Dear Mark,
PostgreSQL will work well if cygwin.dll is compiled in a separate workspace
and installed under C:/program files/postgresql and hidden from users. I
agree it will not be able to serve a 50 TPS system.
Furthermore : MySQL sucks, Windoze sucks and Microsoft is violating our
private rights everyday. So if you care for freedom, we are going to release
this f****** Cygwin minimal installer.
Don't you think my friend? Noone will complain about it. Do you see
demonstrations in the street against Microsoft? The answer is no.
Therefore, I believe noone will complain about a minimal Cygwin + PostgreSQL
installer. This will only be the beginning of a complete Windows port.
Which can also be expressed as :
"Il faut laisser le temps au temps"
"Il n'y a pas le feu au lac"
Cheers,
Jean-Michel
Jean-Michel POURE wrote:
Le Vendredi 10 Mai 2002 15:33, mlw a �crit :
The first time it doesn't work because of anti-virus software, they'll call
it junk. When they test performance and see that it sucks, they'll remove
the software.Dear Mark,
PostgreSQL will work well if cygwin.dll is compiled in a separate workspace
and installed under C:/program files/postgresql and hidden from users. I
agree it will not be able to serve a 50 TPS system.
Then what is the point?
Furthermore : MySQL sucks, Windoze sucks and Microsoft is violating our
private rights everyday. So if you care for freedom, we are going to release
this f****** Cygwin minimal installer.
Don't get me wrong, I would love it if Windows were no longer around. I think a
cygwin version of PostgreSQL will not further your objective. Windows users
will not be seeing the cream of the crop, they will be seeing a quick and dirty
hack. In the words of Martin Luther King, Excellence is the best revenge.
The risk you are taking is this: If you rush out a cygwin version of PostgreSQL
there may be a lasting impression that PostgreSQL is of poor quality.
How will Windows developers create C language function extensions? Using cygwin
and gcc as well? These guys can't do crap without VisualStudio.
Seriously, don't do it. Please don't do it. If we want to make a serious
presence in the Windows market, it is better to take our time and do it well or
not at all.
Don't you think my friend? Noone will complain about it. Do you see
demonstrations in the street against Microsoft? The answer is no.Therefore, I believe noone will complain about a minimal Cygwin + PostgreSQL
installer. This will only be the beginning of a complete Windows port.
I completely disagree. Let me ask you. Have you ever used Windows? I mean as
your primary system? Have you ever thrilled at getting something new for your
Windows system? (Like you do with you current system.)
I'm not ashamed to admit I used to love Windows. Before Linux was usable, and
before FreeBSD was unencumbered, it was the best system a user could get for
the money. Windows was fun, especially if you had the SDK/DDK and knew how to
use it.
Think about Linux and Wine. Linux users do not like Wine applications, no
matter how hidden they are. Franken-wine they are called, and fail quickly.
Look at CorelDraw, a miserable failure. Cygwin on Windows is analogous to Wine
on Linux.
A native PostgreSQL on Windows would rock the Windows world. It would kick
MSSQL's butt for many applications. I think you underestimate Windows and
Windows users if you think a cygwin version will satisfy them. The mistake is
thinking that they are the ignorant unwashed masses that so many UNIX people
seem to think they are.
Then what is the point?
We need more information about Cygwin. See Jason Tishler mail forwarded by
Dave Page.
Don't get me wrong, I would love it if Windows were no longer around. I
think a cygwin version of PostgreSQL will not further your objective.
Windows users will not be seeing the cream of the crop, they will be seeing
a quick and dirty hack. In the words of Martin Luther King, Excellence is
the best revenge.
Microsoft and MySQL conquered the world with converse ideas : releasing crap.
Beside, Cygwin is a very good POSIX emulation. So PostgreSQL + Cygwin wron't
be crap.
How will Windows developers create C language function extensions? Using
cygwin and gcc as well? These guys can't do crap without VisualStudio.
Dev-C++ because mingw and Cygwin can coexist.
Seriously, don't do it. Please don't do it. If we want to make a serious
presence in the Windows market, it is better to take our time and do it
well or not at all.
Well... This is where we disagree. We can do BOTH :
- release a fast Cygwin + PostgreSQL installer,
- port PostgreSQL to native Windows.
I completely disagree. Let me ask you. Have you ever used Windows? I mean
as your primary system? Have you ever thrilled at getting something new for
your Windows system? (Like you do with you current system.)
I stopped using Windows a year ago for political reasons. I stopped using
Windows three years ago in production for non-political reasons. I simply
could not work with such a bad system.
I'm not ashamed to admit I used to love Windows. Before Linux was usable,
and before FreeBSD was unencumbered, it was the best system a user could
get for the money. Windows was fun, especially if you had the SDK/DDK and
knew how to use it.
Sorry my friend, at that time I was sleeping with an Apple IIx and later a
Macintosh. You must have had a hard time debugging Windows 1.0 or 2.0 (which
I read on the list previously). You must have been very lucky to survive. Now
I understand your point of view better ...
A native PostgreSQL on Windows would rock the Windows world. It would kick
MSSQL's butt for many applications. I think you underestimate Windows and
Windows users if you think a cygwin version will satisfy them. The mistake
is thinking that they are the ignorant unwashed masses that so many UNIX
people seem to think they are.
Agreed. But it wron't be ready before 6 months. Meanwhile I would like to come
with a suitable solution to release on http://www.bloodshed.net and feed
hungry developpers that are getting bored with MySQL.
In short, my opinion is
"Le mieux est l'ennemi du bien"
Cheers,
Jean-Michel
mlw <markw@mohawksoft.com> writes:
Without some buy-in from the core team, I'm not sure I am willing to spend my
time on it. If someone would be willing to fund the 100 or so man-hours
required to do it, then that would be a different story.
You are not going to get any buy-in with such ridiculous claims as that.
If the total cost of a native Windows port were O(100 hours), it'd have
been done long since. Add a couple zeroes on the end and I'd start to
believe that you might have some grasp of the problem.
regards, tom lane
Tom Lane wrote:
mlw <markw@mohawksoft.com> writes:
Without some buy-in from the core team, I'm not sure I am willing to spend my
time on it. If someone would be willing to fund the 100 or so man-hours
required to do it, then that would be a different story.You are not going to get any buy-in with such ridiculous claims as that.
If the total cost of a native Windows port were O(100 hours), it'd have
been done long since. Add a couple zeroes on the end and I'd start to
believe that you might have some grasp of the problem.
I was basing my estimates on a couple things. Please feel free to correct me
where I'm wrong. Dann Corbit mentioned a number of, I think I recall, a couple
hundred man-hours for their port.
My approach would be to find all the global variables setup by postmaster, not
all the globals, mind you. Just the ones initialized by postmaster. Move them
to a structure. That structure would be capable of being copied to the child
process.
In the area where forking the postgres process happens, I would ifdef that area
with an "HAS_FORK" The Windows portion would use CreateProcess. The Windows
version of postgres would contact the postmaster and get its copy of the
globals struct. The code to transfer ownership of sockets, files, and memory
would have to be written also.
I would only minimally change the back-end code, it would still be built with
cygwin tools only directed not to link against the cygwin.dll. (The same goes
for the utilities as well.)
A thin port layer could then be constructed by either implementing sysv/UNIX
replacements, or a more simple API as needed in the code, like your shared
memory and semaphore APIs.
Does that sound like an unworkable plan?