Thread: 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 writes:> [ snip ]> Port lib. Regardless where it comes from, the porting code should be a self> contained library, nota list of objects. On Windows, a .DLL can do some things> easier than an application. Also, having a library allows moreflexibility 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 toother 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
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 athttp://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
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.
...
> 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
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 ...
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 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
usekernelservices by normal system calls - this is merely considered normal useof the kernel, and does *not* fall under
theheading of "derived work".Also note that the GPL below is copyrighted by the Free SoftwareFoundation, but the
instanceof code that it refers to (the Linuxkernel) is copyrighted by me and others who actually wrote it.
Also note that the only valid version of the GPL as far as the kernelis concerned is _this_ particular version of the
license(ie v2, notv2.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 portabiliy > > > 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"? 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 portabiliy > > 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. 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
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 > > 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? > > http://www.postgresql.org/users-lounge/docs/faq.html > >
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: >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.
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
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 abit 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 > 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?