Обсуждение: How much work is a native Windows application?
I mentioned in another thread, Windows does not support "fork()." PostgreSQL seems irrevocably tied to using fork(). Without a drastic rewrite of how postmaster works, I don't see a way to make a pure Windows version. The big trick to cygwin is its implementation of fork(). It represents a very important and fairly mature technique. It can be written for PostgreSQL but it would require a fair amount of development time and testing. Then we would need to be able to trace all the native API calls made so that things like file handles are dealt with correctly for the child process. I see cygwin as a portability layer or subsystem, as such, it should be able to emulate foreign operating system constructs. A native application should, on the other hand, not attempt to do so. There is a strategy PostgreSQL could use: Put all global variables which need to be duplicated in a single place, perhaps a struct, which can be copied into the child process. On systems without fork(), the memory can be duplicated or passed around using a shared memory block, on a system with fork(), nothing extra would need to be done. This could be implemented using "standard" APIs, with little or no specialized OS knowledge. This represents a lot of reworking of code, but should not affect much in the way of operation, but would require a lot of typing and testing. It would also force restrictions on module static and global variables. I will sign up to do the Windows stuff to get this to work, but it will take a lot of postgres internal reworking that I am not up for doing. The other alternative, is to profile PostgreSQL running in the cygwin environment and try to assess where any bottlenecks are, and if there are any spot optimizations which can be applied.
http://www.mkssoftware.com/docs/man3/fork.3.asp http://www.computing.net/programming/wwwboard/forum/60.html http://www.research.att.com/sw/tools/uwin (Semaphores & Fork) On Tue, 7 May 2002, mlw wrote: > I mentioned in another thread, Windows does not support "fork()." PostgreSQL > seems irrevocably tied to using fork(). Without a drastic rewrite of how > postmaster works, I don't see a way to make a pure Windows version. > > The big trick to cygwin is its implementation of fork(). It represents a very > important and fairly mature technique. It can be written for PostgreSQL but it > would require a fair amount of development time and testing. > > Then we would need to be able to trace all the native API calls made so that > things like file handles are dealt with correctly for the child process. > > I see cygwin as a portability layer or subsystem, as such, it should be able to > emulate foreign operating system constructs. A native application should, on > the other hand, not attempt to do so. > > There is a strategy PostgreSQL could use: > > Put all global variables which need to be duplicated in a single place, perhaps > a struct, which can be copied into the child process. On systems without > fork(), the memory can be duplicated or passed around using a shared memory > block, on a system with fork(), nothing extra would need to be done. This could > be implemented using "standard" APIs, with little or no specialized OS > knowledge. > > This represents a lot of reworking of code, but should not affect much in the > way of operation, but would require a lot of typing and testing. It would also > force restrictions on module static and global variables. > > I will sign up to do the Windows stuff to get this to work, but it will take a > lot of postgres internal reworking that I am not up for doing. > > The other alternative, is to profile PostgreSQL running in the cygwin > environment and try to assess where any bottlenecks are, and if there are any > spot optimizations which can be applied. >
mlw <markw@mohawksoft.com> writes: > There is a strategy PostgreSQL could use: > Put all global variables which need to be duplicated in a single > place, perhaps a struct, which can be copied into the child > process. On systems without fork(), the memory can be duplicated or > passed around using a shared memory block, on a system with fork(), > nothing extra would need to be done. This could be implemented using > "standard" APIs, with little or no specialized OS knowledge. > This represents a lot of reworking of code, but should not affect much > in the way of operation, but would require a lot of typing and > testing. It would also force restrictions on module static and global > variables. Yeah. The real problem with it in my eyes is that it'd be a continuing maintenance headache: straightforward programming techniques that work fine on all the Unix ports would fail (perhaps in nonobvious ways) when moved to Windows, should you forget to put a variable in the right place. A lesser objection is that variables that can currently be "static" in a single module would become exposed to the world, which again is a maintenance problem. > The other alternative, is to profile PostgreSQL running in the cygwin > environment and try to assess where any bottlenecks are, and if there > are any spot optimizations which can be applied. It'd be worth trying to understand cygwin issues in detail before we sign up to do and support a native Windows port. I understand the user-friendliness objection to cygwin (though one would think proper packaging might largely hide cygwin from naive Windows users). What I don't understand is whether there are any serious performance lossages from it, and if so whether we could work around them. regards, tom lane
"Marc G. Fournier" wrote: > > http://www.mkssoftware.com/docs/man3/fork.3.asp > > http://www.computing.net/programming/wwwboard/forum/60.html > > http://www.research.att.com/sw/tools/uwin (Semaphores & Fork) These are pretty much what I have been saying. Is PostgreSQL going to implement its own fork()? If so, what's the point? Just use cygwin. Without trying to sound conceited, I can write a fork() call, that's not the problem. How much time will it take to do and get right? What about all the infrastructure? Tracking file handles and resources allocated so that they can be properly duplicated for the child process, etc. It is a lot of work, and to do it for a BSD license, I shouldn't reference the cygwin code to do so. The semaphore, shared memory, file API, etc. all these are straight forward. They can be handled with a set of macros and some thin functions. The problems of a native PostgreSQL on Windows is fork(), and all the subtleties that go with it like ownership of system resources allocated by the parent and passed to the child and initialization of global and static variables. Adding fork() to postgres seems silly. Cygwin does it already, and it seems like it is outside the scope of what should be supported by PostgreSQL. Since RedHat owns cygwin and they want RedHat database to be a success, maybe they can make an exception to the GNU license for PostgreSQL. Does anyone think it is a good idea for PostgreSQL to implement it's own version of fork()?
On Tue, 7 May 2002, Tom Lane wrote: > It'd be worth trying to understand cygwin issues in detail before we > sign up to do and support a native Windows port. I understand the > user-friendliness objection to cygwin (though one would think proper > packaging might largely hide cygwin from naive Windows users). What I > don't understand is whether there are any serious performance lossages > from it, and if so whether we could work around them. Actually, there are licensing issues involved ... we could never put a 'windows binary' up for anon-ftp, since to distribute it would require the cygwin.dll to be distributed, and to do that, there is a licensing cost ... of course, I guess we could require ppl to download cygwin seperately, install that, then install the binary over top of that ...
"Marc G. Fournier" <scrappy@hub.org> writes: > On Tue, 7 May 2002, Tom Lane wrote: >> It'd be worth trying to understand cygwin issues in detail before we >> sign up to do and support a native Windows port. > Actually, there are licensing issues involved ... we could never put a > 'windows binary' up for anon-ftp, since to distribute it would require the > cygwin.dll to be distributed, and to do that, there is a licensing cost > ... of course, I guess we could require ppl to download cygwin seperately, > install that, then install the binary over top of that ... <<itch>> And how much development time are we supposed to expend to avoid that? Give me a technical case for avoiding Cygwin, and maybe I can get excited about it. I'm not planning to lift a finger on the basis of licensing though... after all, Windows users are accustomed to paying for software, no? regards, tom lane
... > Give me a technical case for avoiding Cygwin, and maybe I can get > excited about it. I'm not planning to lift a finger on the basis > of licensing though... after all, Windows users are accustomed to > paying for software, no? <evil grin> You tell us: RH sells our database and sells cygwin, so might have an opinion on the subject. Perhaps they would like to contribute back some no cost package licensing terms for cygwin if used for PostgreSQL?? ;) - Thomas
Le Mardi 7 Mai 2002 20:32, mlw a écrit : > Since RedHat owns cygwin and they want RedHat database to be a success, > maybe they can make an exception to the GNU license for PostgreSQL. Cygwin received contributions from several authors. To leave a GNU licence, you need to get the agreement of all authors, which is not possible for a big project like Cygwin. Alternatively, you could pick-up the old static version of Cygwin and release it as a minimal Cygwin dll. This idea is probably ***stupid***. Another possible solution is http://debian-cygwin.sourceforge.net/ project, which tries to port dpkg to Windows. If it was possible to release Cygwin using dpkg, we could create a comprehensive Cygwin + PostgreSQL on-line installer. Why look for complicated solutions when the only real issue for users is the Cygwin installer? Cheers, Jean-Michel POURE
Le Mercredi 8 Mai 2002 06:03, Marc G. Fournier a écrit : > Actually, there are licensing issues involved ... we could never put a > 'windows binary' up for anon-ftp, since to distribute it would require the > cygwin.dll to be distributed, and to do that, there is a licensing cost > ... of course, I guess we could require ppl to download cygwin seperately, > install that, then install the binary over top of that ... This is an installer problem. Let's port dpkg to Windows, create a minimal Cygwin dpkg distribution .. et voilà.
On Wed, 2002-05-08 at 14:02, Jean-Michel POURE wrote: > Le Mardi 7 Mai 2002 20:32, mlw a écrit : > > Since RedHat owns cygwin and they want RedHat database to be a success, > > maybe they can make an exception to the GNU license for PostgreSQL. > > Cygwin received contributions from several authors. To leave a GNU licence, > you need to get the agreement of all authors, which is not possible for a big > project like Cygwin. > > Alternatively, you could pick-up the old static version of Cygwin and release > it as a minimal Cygwin dll. This idea is probably ***stupid***. > > Another possible solution is http://debian-cygwin.sourceforge.net/ project, > which tries to port dpkg to Windows. If it was possible to release Cygwin > using dpkg, we could create a comprehensive Cygwin + PostgreSQL on-line > installer. > > Why look for complicated solutions when the only real issue for users is the > Cygwin installer? IIRC the initial issue was bad performance, which was attributed to win32/cygwin fork() behaviour. That was long before this thread started. BTW, does anyone know how other real databases (Oracle, DB2, Interbase/Firebird, Infomix) do it on Windows. ------------- Hannu
On Wed, 8 May 2002 01:03:37 -0300 (ADT) "Marc G. Fournier" <scrappy@hub.org> wrote: > On Tue, 7 May 2002, Tom Lane wrote: > > > It'd be worth trying to understand cygwin issues in detail before we > > sign up to do and support a native Windows port. I understand the > > user-friendliness objection to cygwin (though one would think proper > > packaging might largely hide cygwin from naive Windows users). What I > > don't understand is whether there are any serious performance lossages > > from it, and if so whether we could work around them. > > Actually, there are licensing issues involved ... we could never put a > 'windows binary' up for anon-ftp, since to distribute it would require the > cygwin.dll to be distributed, and to do that, there is a licensing cost Why? Isn't Cyygwin GPL'd? From http://cygwin.com/licensing.html I don't see anything that would require licensing fees for OSD-compliant software. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Tom Lane > Sent: Tuesday, May 07, 2002 1:49 PM > To: mlw > Cc: Marc G. Fournier; PostgreSQL-development > Subject: Re: [HACKERS] How much work is a native Windows application? > > > It'd be worth trying to understand cygwin issues in detail before we > sign up to do and support a native Windows port. I understand the > user-friendliness objection to cygwin (though one would think proper > packaging might largely hide cygwin from naive Windows users). What > I don't understand is whether there are any serious performance lossages > from it, and if so whether we could work around them. I've sent others to do a cygwin install of PG; it's not at all obvious to them how much of cygwin they need & they end up installing ALL of cygwin (a ton of devel tools, obscure unix utils, etc.) just to get PG working. It would seem not too difficult to package up the cygwin.dll, the handful of shell utils (sh, rm, etc.) req'd by PG, and perhaps even give it a standard Windows installer. Would this be a worthwhile move? Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton Knowledge Management & Technology Consultant
On Wed, 8 May 2002, Neil Conway wrote: > On Wed, 8 May 2002 01:03:37 -0300 (ADT) > "Marc G. Fournier" <scrappy@hub.org> wrote: > > On Tue, 7 May 2002, Tom Lane wrote: > > > > > It'd be worth trying to understand cygwin issues in detail before we > > > sign up to do and support a native Windows port. I understand the > > > user-friendliness objection to cygwin (though one would think proper > > > packaging might largely hide cygwin from naive Windows users). What I > > > don't understand is whether there are any serious performance lossages > > > from it, and if so whether we could work around them. > > > > Actually, there are licensing issues involved ... we could never put a > > 'windows binary' up for anon-ftp, since to distribute it would require the > > cygwin.dll to be distributed, and to do that, there is a licensing cost > > Why? Isn't Cyygwin GPL'd? From http://cygwin.com/licensing.html I don't > see anything that would require licensing fees for OSD-compliant software. I may be wrong about this ... this was prior to Redhat buying it out, which I totally forgot about ...
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Marc G. Fournier > Sent: Wednesday, May 08, 2002 12:04 AM > To: Tom Lane > Cc: mlw; PostgreSQL-development > Subject: Re: [HACKERS] How much work is a native Windows application? > > > On Tue, 7 May 2002, Tom Lane wrote: > > > It'd be worth trying to understand cygwin issues in detail before we > > sign up to do and support a native Windows port. I understand the > > user-friendliness objection to cygwin (though one would think proper > > packaging might largely hide cygwin from naive Windows users). What I > > don't understand is whether there are any serious performance lossages > > from it, and if so whether we could work around them. > > Actually, there are licensing issues involved ... we could never put a > 'windows binary' up for anon-ftp, since to distribute it would require the > cygwin.dll to be distributed, and to do that, there is a licensing cost > ... of course, I guess we could require ppl to download cygwin seperately, > install that, then install the binary over top of that ... From http://cygwin.com/licensing.html: """ In accordance with section 10 of the GPL, Red Hat permits programs whose sources are distributed under a license that complies with the Open Source definition to be linked with libcygwin.a without libcygwin.a itself causing the resulting program to be covered by the GNU GPL. This means that you can port an Open Source(tm) application to cygwin, and distribute that executable as if it didn't include a copy of libcygwin.a linked into it. Note that this does not apply to the cygwin DLL itself. If you distribute a (possibly modified) version of the DLL you must adhere to the terms of the GPL, i.e. you must provide sources for the cygwin DLL. See http://www.opensource.org/osd.html for the precise Open Source Definition referenced above. """ Not following this exactly, but would this give PG the exception it needs (my eyes start to glaze over on stuff like this)? Anyone from RedHat still on this list? In any event, if PG can't release a PG+Cygwin in one package, we could maintain a official web page about how to get PG running under Cygwin that walks through exactly what to install, how to install, and how to set up. There are some notes at http://www.ca.postgresql.org/docs/faq-mswin.html, but these are assuming that you want to build PG, rather than simply install PG from the cygwin packages. I'd be very willing to help with this effort, once there's some consensus on what direction we want to head. - J. Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton Knowledge Management & Technology Consultant
"Marc G. Fournier" <scrappy@hub.org> writes: > On Tue, 7 May 2002, Tom Lane wrote: > > > It'd be worth trying to understand cygwin issues in detail before we > > sign up to do and support a native Windows port. I understand the > > user-friendliness objection to cygwin (though one would think proper > > packaging might largely hide cygwin from naive Windows users). What I > > don't understand is whether there are any serious performance lossages > > from it, and if so whether we could work around them. > > Actually, there are licensing issues involved ... we could never put > a 'windows binary' up for anon-ftp, since to distribute it would > require the cygwin.dll to be distributed, and to do that, there is a > licensing cost ... of course, I guess we could require ppl to > download cygwin seperately, install that, then install the binary > over top of that ... From the Cygwin FAQ: Is it free software? Yes. Parts are GNU software (gcc, gas, ld, etc...), parts are covered by the standard X11 license, some of itis public domain, some of it was written by Cygnus and placed under the GPL. None of it is shareware. You don'thave to pay anyone to use it but you should be sure to read the copyright section of the FAQ more more informationon how the GNU General Public License may affect your use of these tools. There is even a clause allowing you to link to the cygwin dll without your software falling under the GPL if your software is released under a license that complies with the Open Source Definition. *** NOTE *** In accordance with section 10 of the GPL, Red Hat permits programs whose sources are distributed under a licensethat complies with the Open Source definition to be linked with libcygwin.a without libcygwin.a itselfcausing the resulting program to be covered by the GNU GPL. This means that you can port an Open Source(tm) application to cygwin, and distribute that executable as ifit didn't include a copy of libcygwin.a linked into it. Note that this does not apply to the cygwin DLL itself.If you distribute a (possibly modified) version of the DLL you must adhere to the terms of the GPL, i.e.you must provide sources for the cygwin DLL. See http://www.opensource.org/osd.html for the precise Open Source Definition referenced above. Red Hat sells a special Cygwin License for customers who are unable to provide their application in open sourcecode form. For more information, please see: http://www.redhat.com/software/tools/cygwin/, or call 866-2REDHAT ext. 3007 In other words, you could even distribute a BSD licensed PostgreSQL that that ran on Windows. Not that such a loophole is particularly useful. GPL projects regularly include BSD code, this doesn't make the BSD version GPLed. The GPL might be viral in nature, but it's not that viral. Now, I can understand why the PostgreSQL mirrors might be a little bit concerned about distributing GPLed software, because of the legal ramifications, but they could leave the distribution of Cygwin up to RedHat, and simply distribute a BSD-licensed PostgreSQL Windows binary. Jason
On Tue, May 07, 2002 at 01:16:01PM -0400, mlw wrote: > I mentioned in another thread, Windows does not support "fork()." PostgreSQL > seems irrevocably tied to using fork(). Without a drastic rewrite of how > postmaster works, I don't see a way to make a pure Windows version. I watch this discussion and only one question is still in my head:how much people use Windows for server side part of stableapplication based Oracle or DB2? Why my employer spend a lot of money withSGI cluster + IRIX? _IMHO_ if you want support Windows, please, write good tools for admins, DB designers and developers (forms?). The serveris really not a problem if you think about real DB application. There is more important things in ourTODO than supportGUI-OS for server running... (IMHO:-) Karel -- Karel Zak <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
Le Jeudi 9 Mai 2002 09:25, Karel Zak a écrit : > _IMHO_ if you want support Windows, please, write good tools for admins, > DB designers and developers (forms?). The server is really not a problem > if you think about real DB application. There is more important things in > our TODO than support GUI-OS for server running... (IMHO:-) Try pgAdmin2 (http://pgadmin.postgresql.org. Other project are in the hub. Mono port for example.
Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> writes: > > On Tue, 7 May 2002, Tom Lane wrote: > >> It'd be worth trying to understand cygwin issues in detail before we > >> sign up to do and support a native Windows port. > > > Actually, there are licensing issues involved ... we could never put a > > 'windows binary' up for anon-ftp, since to distribute it would require the > > cygwin.dll to be distributed, and to do that, there is a licensing cost > > ... of course, I guess we could require ppl to download cygwin seperately, > > install that, then install the binary over top of that ... > > <<itch>> And how much development time are we supposed to expend to > avoid that? > > Give me a technical case for avoiding Cygwin, and maybe I can get > excited about it. I'm not planning to lift a finger on the basis > of licensing though... after all, Windows users are accustomed to > paying for software, no? Nobody asked you to lift any of your fingers. A few people (including me) just see value in a native Windows port, kicking out the Cygwin requirement. I have the impression you never did use Cygwin. I did, thanks but no thanks. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck wrote: > > Tom Lane wrote: > > "Marc G. Fournier" <scrappy@hub.org> writes: > > > On Tue, 7 May 2002, Tom Lane wrote: > > >> It'd be worth trying to understand cygwin issues in detail before we > > >> sign up to do and support a native Windows port. > > > > > Actually, there are licensing issues involved ... we could never put a > > > 'windows binary' up for anon-ftp, since to distribute it would require the > > > cygwin.dll to be distributed, and to do that, there is a licensing cost > > > ... of course, I guess we could require ppl to download cygwin seperately, > > > install that, then install the binary over top of that ... > > > > <<itch>> And how much development time are we supposed to expend to > > avoid that? > > > > Give me a technical case for avoiding Cygwin, and maybe I can get > > excited about it. I'm not planning to lift a finger on the basis > > of licensing though... after all, Windows users are accustomed to > > paying for software, no? > > Nobody asked you to lift any of your fingers. A few people > (including me) just see value in a native Windows port, > kicking out the Cygwin requirement. > > I have the impression you never did use Cygwin. I did, thanks > but no thanks. I have used the cygwin version too. It is a waste of time. No Windows user will ever accept it. No windows-only user is going to use the cygwin tools. From a production stand point, would anyone reading this trust their data to PostgreSQL running on cygwin? Think about it, if you wouldn't, why would anyone else. I think, and I know people are probably sick of me spouting opinions, that if you want a Windows presence for PostgreSQL, then we should write a real Win32 version. If the global/static variables which are initialized by the postmaster are moved to a structure, we can should be able to remove the fork() requirement and port to a Win32 native system.
Jan Wieck writes:> Tom Lane wrote:> > Give me a technical case for avoiding Cygwin, and maybe I can get> > excited aboutit. I'm not planning to lift a finger on the basis> > of licensing though... after all, Windows users are accustomedto> > paying for software, no?> Nobody asked you to lift any of your fingers. A few people> (includingme) just see value in a native Windows port,> kicking out the Cygwin requirement.> I have the impressionyou never did use Cygwin. I did, thanks> but no thanks. I think the crux of the the problem is that a native Windows port would require a LOT of changes in the source (switching over to API wrappers, adding compatibility layers). Obviously this has the possibility of introducing a lot of bugs with zero gain for the folk who are already happily running PostgreSQL on UNIX-like systems. And what of performance? Sure It'd be nice to have a native PostgreSQL on XP Server (I don't see the point in consumer level Microsoft OSs) but how high is the demand? What's the prize? What are the current limitations - fork, semaphores, ugly interface...? Lee.
mlw <markw@mohawksoft.com> writes: > I have used the cygwin version too. It is a waste of time. No Windows user will > ever accept it. No windows-only user is going to use the cygwin tools. With decent packaging, no windows-only user would even know we have cygwin in there. The above argument is just plain irrelevant. The real point is that we need a nice clean friendly GUI for both installation and administration --- and AFAICS that will take about the same amount of work to write whether the server requires cygwin internally or not. Rather than expending largely-pointless work on internal rewrites of the server, people who care about this issue ought to be thinking about the GUI problems. > From a production stand point, would anyone reading this trust their > data to PostgreSQL running on cygwin? I wouldn't trust my data to *any* database running on a Microsoft OS. Period. The above argument thus doesn't impress me at all, especially when it's being made without offering a shred of evidence that cygwin contributes any major degree of instability. I am especially unhappy about the prospect of major code revisions and development time spent on chasing this rather than improving our performance and stability on Unix-type OSes. I agree with the comment someone else made: that's just playing Microsoft's game. regards, tom lane
Lee Kindness wrote: > > Sure It'd be nice to have a native PostgreSQL on XP Server (I don't > see the point in consumer level Microsoft OSs) but how high is the > demand? What's the prize? What are the current limitations - fork, > semaphores, ugly interface...? The demand for PostgreSQL on Windows is currently as near to zero as you can imagine. This is probably because there is no viable PostgreSQL on Windows. If written correctly, a Win32 version of PostgreSQL would rock the Windows world. I see no reason why it would be limted to the "professional" version. Hell, it could even run on Windows 98. Right now, in the small to medium space, there is only one choice for Windows, MSSQL. It requires the "professional" or server versions of the Microsoft platforms. PostgreSQL could come in and run on all of them. PostgreSQL's feature set and price ($0), with a good installer, would do VERY well.
Tom Lane wrote: > With decent packaging, no windows-only user would even know we have > cygwin in there. The above argument is just plain irrelevant. The real > point is that we need a nice clean friendly GUI for both installation > and administration --- and AFAICS that will take about the same amount of > work to write whether the server requires cygwin internally or not. Can a cygwin version of PostgreSQL see the native file system, like: C:\My Database, D:\postgres? > > From a production stand point, would anyone reading this trust their > > data to PostgreSQL running on cygwin? > > I wouldn't trust my data to *any* database running on a Microsoft OS. That is a prejudice that is affecting your judgment. Many people do trust Windows, do I? No, but a lot of people do. People have trusted their businesses on Windows NT/2K/XP, many are still doing so. We want these people to use PostgreSQL, so when they see the error in their ways, they have a way out. > The above argument thus doesn't impress me at all, especially > when it's being made without offering a shred of evidence that cygwin > contributes any major degree of instability. From a software development standpoint, I am VERY uncomfortable with the technique of a user space program copying its writeable memory to another process's. It may work until Microsoft changes something with the next version of IE. What about anti-virus software, cygwin has problems with them, and you have to have anti-virus software on Windows. On top of that, the time spent copying the whole process is too long, and it forces real memory to be allocated and initialized at process startup. So, the cygwin fork() will cause PostgreSQL to be slower and use more memory than a native version, and will not co-exist well with anti-virus software. > > I am especially unhappy about the prospect of major code revisions > and development time spent on chasing this rather than improving our > performance and stability on Unix-type OSes. I agree with the comment > someone else made: that's just playing Microsoft's game. Maybe is is playing "Microsoft's Game" but the end result will be a program that can seriously compete with MSSQL on Windows, and provide a REAL migration path to UNIX. Many developers use MSSQL because they "have it" in MSDN, so to them, it is free. Once they develop something using it, they are tied to Windows. When it comes time to deploy their pet project, the company has to cough up the price of the server. A native, friendly, Win32 PostgreSQL that works the same on Windows as it does on FreeBSD, Linux, Solaris, etc. Will offer the developer real options away from Windows. Also: I don't think it needs to be a major rewrite, no strategy needs to change, it is basically renaming variables, i.e. my_global_var becomes pg_globals.my_global_var. Once that is done, a port writer can do what ever they need to do to get that structure to the child correctly. As an exercise, I bet if we did this, we would find bugs which are lurking, as yet unfound. Besides, the discipline of using a globals structure will improve the code base. Don't you agree?
... > PostgreSQL's feature set and price ($0), with a good installer, would do VERY > well. That may be (I'd like to think so!). We've identified at least a couple of barriers to folks running PostgreSQL on Windows. The installer and GUI issue needs to be solved no matter what, and we *could* have a version running on Windows with just those things in place. imho if we are going down the path, we need to take the first steps. And those do *not* require code rewrites to do so (or at least don't appear to). If we had a package available for Windows -- with some developers such as yourself supporting it -- then we could talk about putting more resources into supporting that platform better. But the perception of at least some of the key developers (including myself) is that *if* we did the code rewrite, and *if* we spent the effort to end up as a native on Windows, then we *very well might* be an unreliable database on an unreliable platform. istm that getting a well packaged system running now, then being able to identify *only cygwin* as the barrier to better reliability would get more support for changes in the backend code. And if we were working toward some ability to do threading anyway (I don't see that in the near future, but we've talked in the past about structuring the query engine around "tuple sources" which could then be distributed across threads or across machines) then maybe the next step is easier. My 2c... - Thomas
There are some issues that the whole idea of a win32 port should bring up. One of them is whether or not postgresql should be rewritten as a multi-threaded app. If postgresql will never be rewritten as a multi-threaded app, then performance under Windows is likely to ALWAYS be slow, since that multi-thread is the preferred model for good performance on W32. note that many Unixes prefer multi-threaded models as well (Solaris comes to mind) so there's the possibility that a multi-threaded postgresql could enjoy better performance on more than just windows. If postgresql IS going to eventually be multi-threaded, then the whole win32 port should probably be delayed until then, since it would solve many of the issues of fork() versus createprocess(). Just my thoughts on it. Scott
mlw wrote: > I think, and I know people are probably sick of me spouting opinions, that if > you want a Windows presence for PostgreSQL, then we should write a real Win32 > version. > > If the global/static variables which are initialized by the postmaster are > moved to a structure, we can should be able to remove the fork() requirement > and port to a Win32 native system. My opinion here is that until May 1998 Postgres did exec(), so it was clean and okay for CreateProcess() up to then.Just because we optimized it for the copy-on-write behaviour, modern Unix kernels do with fork() only, is NO reason to accept sloppy coding. The Postmaster and the backend have different responsibilities. In fact,I still consider them beeing different programs even if they reside in one executable. Mixing globalvariables of one with the other is wrong. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
mlw wrote: > Can a cygwin version of PostgreSQL see the native file system, like: C:\My > Database, D:\postgres? Sort of. C:\My Database becomes /cygdrive/c/My Database under cygwin. So the path names need to be munged, but you can access the entire windows filesystem from within cygwin. --Barry
> Lee Kindness wrote: >> Sure It'd be nice to have a native PostgreSQL on XP Server (I don't >> see the point in consumer level Microsoft OSs) but how high is the >> demand? What's the prize? What are the current limitations - fork, >> semaphores, ugly interface...? > The demand for PostgreSQL on Windows is currently as near to zero > as you can imagine. This is probably because there is no viable > PostgreSQL on Windows. > > If written correctly, a Win32 version of PostgreSQL would rock > the Windows world. I see no reason why it would be limted to the > "professional" version. Hell, it could even run on Windows 98. > > Right now, in the small to medium space, there is only one choice for > Windows, MSSQL. It requires the "professional" or server versions of > the Microsoft platforms. PostgreSQL could come in and run on all of > them. > > PostgreSQL's feature set and price ($0), with a good installer, would > do VERY well. If "fixing" PostgreSQL to "work" on Win32 caused a whole lot of breakage on the Unix side, that would _not_ be a "win." It might do well on Win32, but breakage could lead to a LOSS of interest on Unix, as people decided to take the point ofview that the developers considered it more important to toady to Win-Needs than to improve how it works on Unix. Is that a totally "fair" point of view? No, but in a world where New York office buildings get bombed resulting in absolutelybizarre combinations of cheering and jeering, an expectation of "fairness" is definitely too much to ask. (Youwon't get anything resembling "fairness" at the airport, that's for sure...) How about a totally different perspective: Why not let someone else go after the Windows "market"? People are actively working on SAP-DB and Firebird, and putting pretty serious efforts into the Win32 side of those databasesystems. How outrageous an idea is it to say: "Let them deal with that set of headaches?" Aside from that, there's also the "Show me the patch" option. If someone is excited about porting PostgreSQL to Win32, nothingis stopping them from doing so, and contributing patches back. There seem to be several such efforts out there; ifone becomes mature enough, it may represent a useful basis to port in to make the main codebase "more portable." There are at least the two clear options: - Other DBs; - Volunteers porting PostgreSQL to Win32. If a "winner" emerges, that would surely be useful to guide later PostgreSQL efforts. -- (reverse (concatenate 'string "gro.mca@" "enworbbc")) http://www.cbbrowne.com/info/wp.html "What you end up with, after running an operating system concept through these many marketing coffee filters, is something not unlike plain hot water." -- Matt Welsh -- (reverse (concatenate 'string "moc.enworbbc@" "enworbbc")) http://www3.sympatico.ca/cbbrowne/sap.html "I'm not switching from slrn. I'm quite confident that anything that *needs* to be posted in HTML is fatuous garbage not worth my time." -- David M. Cook <davecook@home.com>
> I think, and I know people are probably sick of me spouting opinions, > that if you want a Windows presence for PostgreSQL, then we should > write a real Win32 version. The crucial wrong word is the word "we." If _you_ want a Windows presence, then _you_ should write a real Win32 version. That clearly attaches responsibility to someone who is interested. -- (reverse (concatenate 'string "gro.mca@" "enworbbc")) http://www.cbbrowne.com/info/unix.html "I'm not switching from slrn. I'm quite confident that anything that *needs* to be posted in HTML is fatuous garbage not worth my time." -- David M. Cook <davecook@home.com> -- (reverse (concatenate 'string "moc.enworbbc@" "enworbbc")) http://www.ntlug.org/~cbbrowne/spreadsheets.html Rules of the Evil Overlord #166. "If the rebels manage to trick me, I will make a note of what they did so that I do not keep falling for the same trick over and over again." <http://www.eviloverlord.com/>
cbbrowne@cbbrowne.com wrote: > > > I think, and I know people are probably sick of me spouting opinions, > > that if you want a Windows presence for PostgreSQL, then we should > > write a real Win32 version. > > The crucial wrong word is the word "we." > > If _you_ want a Windows presence, then _you_ should write a real Win32 > version. That clearly attaches responsibility to someone who is interested. I have already said that I am willing to write the pieces for a Windows port. The issue is changes in PostgreSQL required to do it.
Christopher Browne wrote: > > If "fixing" PostgreSQL to "work" on Win32 caused a whole lot of > breakage on the Unix side, that would _not_ be a "win." It might > do well on Win32, but breakage could lead to a LOSS of interest > on Unix, as people decided to take the point of view that the > developers considered it more important to toady to Win-Needs > than to improve how it works on Unix. As a PostgreSQL user, I *wholeheartedly* agree. I have no need nor interest in a Win32 solution. Period. If I perceive that an effort to add a Win32 postgresql is adversely impacting the ongoing development of Unix-based PostgreSQL then I will start looking at other solutions. In fact, if you folks could find additional resources that would support Win32 development, it still seems to me that perhaps those resources could be better spent improving the Unix version. -- Steve Wampler -- swampler@noao.edu O sibile, si ergo. Fortibus es enaro. Nobile, demis trux. Demis phulla causan dux.
Scott Marlowe wrote: > > There are some issues that the whole idea of a win32 port should bring up. > One of them is whether or not postgresql should be rewritten as a > multi-threaded app. Perhaps. > > If postgresql will never be rewritten as a multi-threaded app, then > performance under Windows is likely to ALWAYS be slow, since that > multi-thread is the preferred model for good performance on W32. There are methods for reducing process creation load on Windows. One way is to make PostgreSQL one big .DLL and just spin off a small program. A windows .DLL is different than a UNIX shared library, in some ways better, in other ways worse, either way, it is a usefull tool. > note > that many Unixes prefer multi-threaded models as well (Solaris comes to > mind) so there's the possibility that a multi-threaded postgresql could > enjoy better performance on more than just windows. The isolation of a process is very important to reliable operation. Going threaded usually means allowing a single connection to bring down the whole server.
Le Jeudi 9 Mai 2002 16:55, mlw a écrit : > Can a cygwin version of PostgreSQL see the native file system, like: C:\My > Database, D:\postgres? You have the choice to keep Windows or Unix paths. Both are supported. /Jean-Michel POURE
> cbbrowne@cbbrowne.com wrote: >>> I think, and I know people are probably sick of me spouting >>> opinions, that if you want a Windows presence for PostgreSQL, then >>> we should write a real Win32 version. >> >> The crucial wrong word is the word "we." >> If _you_ want a Windows presence, then _you_ should write a real >> Win32 version. That clearly attaches responsibility to someone who >> is interested. > I have already said that I am willing to write the pieces for a > Windows port. The issue is changes in PostgreSQL required to do it. No, I don't think you understand. If you're planning to do a port, then _all_ changes are your responsibility. Nobody ought to need to change PostgreSQL in order for you to write a Windows port; that, in fact, would be a waste of time, having several people working on something that should probably be done by one person. -- (concatenate 'string "aa454" "@freenet.carleton.ca") http://www.ntlug.org/~cbbrowne/x.html Why are they called apartments, when they're all stuck together?
Scott Marlowe wrote: > There are some issues that the whole idea of a win32 port should bring up. > One of them is whether or not postgresql should be rewritten as a > multi-threaded app. Please, don't add this one to it. I'm all for the native Windows port, yes, but I've discussed the multi-thread questions for days at Great Bridge, then again with my new employer, with people on shows and whatnot. Anything in the whole backend is designed with a multi- process model in mind. You'll not do that in any reasonable amount of time. > If postgresql will never be rewritten as a multi-threaded app, then > performance under Windows is likely to ALWAYS be slow, since that > multi-thread is the preferred model for good performance on W32. note > that many Unixes prefer multi-threaded models as well (Solaris comes to > mind) so there's the possibility that a multi-threaded postgresql could > enjoy better performance on more than just windows. As soon as you switch to a multi-threaded middle tier, that uses connection pools and avoids constant process creation,I think you don't have much of a problem any more. The high connect/disconnect ratio, acceptable for threadeddatabases, is what kills PostgreSQL. > If postgresql IS going to eventually be multi-threaded, then the whole > win32 port should probably be delayed until then, since it would solve > many of the issues of fork() versus createprocess(). If multi-threading is the plan, then there is light at the end of the tunnel ... the upcoming train... Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On Thu, 9 May 2002, Jan Wieck wrote: > > If postgresql IS going to eventually be multi-threaded, then the whole > > win32 port should probably be delayed until then, since it would solve > > many of the issues of fork() versus createprocess(). > > If multi-threading is the plan, then there is light at the > end of the tunnel ... the upcoming train... That's a bit extreme don't you think? I'm not fan of multi-threading as the one true way, and since I use linux as my server for postgresql, there is no gain for me in a multi-threaded model. In fact, I'd prefer postgresql stay multi-process for robustness. BUT, if there are plans to go multi-thread, or could be plans, then those should take priority over how to port to windows, since making postgresql multi-threaded will change it so much as to make the current "how do we port to windows" thread meaningless. One of the primary reasons given for avoiding cygwin is that postgresql runs so slowly under it on windows, but I submit that it probably won't run a heck of a lot faster if it was written as a native app as long as it's running as a multi-process design. Since there's probably no great gain to be had from moving it out from under cygwin, why bother? My vote would be to stay multi-process and Unix compatible. I have no real use for windows as a server, and do NOT want to sacrifice the performance / reliability I have with postgresql under Linux for a windows port.
cbbrowne@cbbrowne.com wrote: > > > cbbrowne@cbbrowne.com wrote: > >>> I think, and I know people are probably sick of me spouting > >>> opinions, that if you want a Windows presence for PostgreSQL, then > >>> we should write a real Win32 version. > >> > >> The crucial wrong word is the word "we." > > >> If _you_ want a Windows presence, then _you_ should write a real > >> Win32 version. That clearly attaches responsibility to someone who > >> is interested. > > > I have already said that I am willing to write the pieces for a > > Windows port. The issue is changes in PostgreSQL required to do it. > > No, I don't think you understand. > > If you're planning to do a port, then _all_ changes are your > responsibility. Nobody ought to need to change PostgreSQL in order for > you to write a Windows port; that, in fact, would be a waste of time, > having several people working on something that should probably be done > by one person. Without buy-in from the group, there is no point in me wasting my time doing all the work necessary. I'm not interested in making Mark's special version of PostgreSQL. If we can agree on a strategy and a course, then it is worth doing. If all the changes made fall on the floor because the group does not like them, then I wasted my time. Got it? Also, doing the Windows portions of the code will represent a significant investment of my time. I'm not interested in doing a lot of work on a shoddy project. If you ask the core group to put out a crappy version of PostgreSQL for a UNIX, they would fight long and hard against it. Why should we be willing to produce a crappy version for Windows, just because the people here don't like Windows. I don't care about Solaris, but I understand WHY it is important to make PostgreSQL work well on it. I don't understand why the people in this group don't see the same purpose for a Windows port. To be honest, I think a good Windows port will do wonders for PostgreSQL's acceptance.
cbbrowne@cbbrowne.com wrote: > > cbbrowne@cbbrowne.com wrote: > >>> I think, and I know people are probably sick of me spouting > >>> opinions, that if you want a Windows presence for PostgreSQL, then > >>> we should write a real Win32 version. > >> > >> The crucial wrong word is the word "we." > > >> If _you_ want a Windows presence, then _you_ should write a real > >> Win32 version. That clearly attaches responsibility to someone who > >> is interested. > > > I have already said that I am willing to write the pieces for a > > Windows port. The issue is changes in PostgreSQL required to do it. > > No, I don't think you understand. > > If you're planning to do a port, then _all_ changes are your > responsibility. Nobody ought to need to change PostgreSQL in order for > you to write a Windows port; that, in fact, would be a waste of time, > having several people working on something that should probably be done > by one person. Who said PostgreSQL shall not support any other OS than *NIX or things that look alike? When I first used Postgres, it still had a VMS port. Well, we dropped the VMS port at some point, when we wherepretty sure it was broken and nobody complained. Now we face the fact that Microsoft managed to create something useful (other than a joystick or optical mouse,I mean Win2K). And as a logical consequence more and more people ask for support of their OS. A good deal of effort in the original Postgres was about portability. I hope we've not become a UNIX-only show. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On Thu, 2002-05-09 at 22:36, mlw wrote: > Scott Marlowe wrote: > > note > > that many Unixes prefer multi-threaded models as well (Solaris comes to > > mind) so there's the possibility that a multi-threaded postgresql could > > enjoy better performance on more than just windows. > > The isolation of a process is very important to reliable operation. Going > threaded usually means allowing a single connection to bring down the whole > server. AFAIK we do that already in forked model - any time postmaster thinks that a dying child has corrupted shared memory it kills all its children. -------- Hannu
On Thu, 2002-05-09 at 22:51, Jan Wieck wrote: > Scott Marlowe wrote: > > There are some issues that the whole idea of a win32 port should bring up. > > One of them is whether or not postgresql should be rewritten as a > > multi-threaded app. > > Please, don't add this one to it. > > I'm all for the native Windows port, yes, but I've discussed > the multi-thread questions for days at Great Bridge, then > again with my new employer, with people on shows and whatnot. > > Anything in the whole backend is designed with a multi- > process model in mind. You'll not do that in any reasonable > amount of time. IIRC you are replying to the man who _has_ actually don this ? Perhaps using an unreasonable amount of time but still ... :) ---------- Hannu
Hannu Krosing wrote: > > On Thu, 2002-05-09 at 22:36, mlw wrote: > > Scott Marlowe wrote: > > > note > > > that many Unixes prefer multi-threaded models as well (Solaris comes to > > > mind) so there's the possibility that a multi-threaded postgresql could > > > enjoy better performance on more than just windows. > > > > The isolation of a process is very important to reliable operation. Going > > threaded usually means allowing a single connection to bring down the whole > > server. > > AFAIK we do that already in forked model - any time postmaster thinks > that a dying child has corrupted shared memory it kills all its > children. I know there are cases when postmaster will kill all its children, but take the case of a faulty user function that gets a segfault. That process dies and the others continue. Without a lot of OS specific crap in postgres, that sort of behavior would be difficult to have with a threaded server.
On Fri, 2002-05-10 at 00:09, Hannu Krosing wrote: > On Thu, 2002-05-09 at 22:51, Jan Wieck wrote: > > Scott Marlowe wrote: > > > There are some issues that the whole idea of a win32 port should bring up. > > > One of them is whether or not postgresql should be rewritten as a > > > multi-threaded app. > > > > Please, don't add this one to it. > > > > I'm all for the native Windows port, yes, but I've discussed > > the multi-thread questions for days at Great Bridge, then > > again with my new employer, with people on shows and whatnot. > > > > Anything in the whole backend is designed with a multi- > > process model in mind. You'll not do that in any reasonable > > amount of time. > > IIRC you are replying to the man who _has_ actually don this ? Sorry, mistaken identity. I meant Myron scott ( mkscott@sacadia.com ) who has made this http://sourceforge.net/projects/mtpgsql > Perhaps using an unreasonable amount of time but still ... :) > > ---------- > Hannu >
On Thu, 2002-05-09 at 19:23, mlw wrote: > Lee Kindness wrote: > > > > > Sure It'd be nice to have a native PostgreSQL on XP Server (I don't > > see the point in consumer level Microsoft OSs) but how high is the > > demand? What's the prize? What are the current limitations - fork, > > semaphores, ugly interface...? > > The demand for PostgreSQL on Windows is currently as near to zero as you can > imagine. This is probably because there is no viable PostgreSQL on Windows. > > If written correctly, a Win32 version of PostgreSQL would rock the Windows > world. I see no reason why it would be limted to the "professional" version. > Hell, it could even run on Windows 98. Perhaps we could simpultaneously solve another problem - creating a singlethreaded embeddable version of postgresql "engine" ------------- Hannu
On Thu, 2002-05-09 at 19:25, Tom Lane wrote: > mlw <markw@mohawksoft.com> writes: > > I have used the cygwin version too. It is a waste of time. No Windows user will > > ever accept it. No windows-only user is going to use the cygwin tools. > > With decent packaging, no windows-only user would even know we have > cygwin in there. The above argument is just plain irrelevant. The real > point is that we need a nice clean friendly GUI for both installation > and administration --- and AFAICS that will take about the same amount of > work to write whether the server requires cygwin internally or not. <evil grin> We can go the Oracle way and write a 200MB cross-platform java installer requiring and exact version of java runtime </evil grin> > Rather than expending largely-pointless work on internal rewrites of > the server, people who care about this issue ought to be thinking about > the GUI problems. pgAccess is quite nice (Disclaimer: I'm not a windows weenie, I run it inside vmware/win98 IE browser test environment on my Linux workstation ;). Why not just bundle what we've got ? > > From a production stand point, would anyone reading this trust their > > data to PostgreSQL running on cygwin? > > I wouldn't trust my data to *any* database running on a Microsoft OS. > Period. Do we support Xenix and SCO ? > The above argument thus doesn't impress me at all, especially > when it's being made without offering a shred of evidence that cygwin > contributes any major degree of instability. From the comments here it seems to be either cygwin or more likely cygipc > I am especially unhappy about the prospect of major code revisions > and development time spent on chasing this rather than improving our > performance and stability on Unix-type OSes. I agree with the comment > someone else made: that's just playing Microsoft's game. Not! I think that this thread is mostly about coordinating code and interface cleanups that are likely beneficial for both *NIX and non-*NIX platforms mainly* cleaner support for semaphores* separating shared and per-process data* process creation* (file operations)* (initand service scripts) if done properly none of these will degrade code quality nor performance. Also, having a clean interface for those will not only enable any interested party to make windows/BeOS/OSX/QNX binaries with less effort, it will most likely make it easier make use of advances in *NIX world like AIO, multiprocessor systems, NUMA and distributed systems, and just make things more robust and reliable by making code inspection easier. --------------- Hannu
Tom Lane <tgl@sss.pgh.pa.us> writes: > mlw <markw@mohawksoft.com> writes: > > I have used the cygwin version too. It is a waste of time. No Windows user will > > ever accept it. No windows-only user is going to use the cygwin tools. > > With decent packaging, no windows-only user would even know we have > cygwin in there. The above argument is just plain irrelevant. The real > point is that we need a nice clean friendly GUI for both installation > and administration --- and AFAICS that will take about the same amount of > work to write whether the server requires cygwin internally or not. I'm afraid I agree with mlw, Tom. I don't think the problem ends at the GUI, although for many people it would. The issue extends at least also to support and troubleshooting. In a production environment, I have a better chance of figuring out what's going wrong with an application written natively for an operating system dealing directly with that operating system. I would take a dim view of using PostgreSQL running on cygwin unless I had extensive experience doing it, or if there were no other alternative. > > From a production stand point, would anyone reading this trust their > > data to PostgreSQL running on cygwin? > > I wouldn't trust my data to *any* database running on a Microsoft OS. > Period. The above argument thus doesn't impress me at all, especially > when it's being made without offering a shred of evidence that cygwin > contributes any major degree of instability. If you could prove to me that cygwin doesn't contribute *any* instability, I'd still be pretty worried, probably for the same reasons that you don't trust any Microsoft OS. There are increased chances that something could go critically wrong, particularly in an environment fundamentally different. I think mlw's basic point is quite valid, that PG+cygwin will not ever find favor with decision-makers who are used to Windows systems. Suspicion of the other environment's foibles is common, and goes both ways. > I am especially unhappy about the prospect of major code revisions > and development time spent on chasing this rather than improving our > performance and stability on Unix-type OSes. I agree with the comment > someone else made: that's just playing Microsoft's game. There I don't deny you may be right. Ernie Gutierrez Walnut Creek, CA