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
