Thread: OK, lets talk portability.
As I set out to do the Windows semaphore thing, I notice it can get quite ugly. In the current CVS directory, there is pgsql/src/backend/port directory. I propose that this become a separate subproject and library. The reason I want this is because the semaphore support, specifically multiple semaphores identified by a single key, has to be implemented with shared memory and multiple semaphores. (Under Windows) I also have to look at "ownership" issues with Windows processes and shared objects. They may need to be own be a more persistent/independent module, a DLL. By creating a library like "libpgport.a" (or on Windows pgport.dll/pgport.lib) little has to be changed for various ports. If we don't have the library then the discrete object filed would need to be specified. The library will give the port writer a greater amount of flexibility. Comments?
mlw <markw@mohawksoft.com> writes:
> In the current CVS directory, there is pgsql/src/backend/port directory.
> I propose that this become a separate subproject and library.
Right offhand, that seems a pointless exercise in relabeling code that's
going to be the same either way. What's the actual value?
> The reason I want this is because the semaphore support, specifically
> multiple semaphores identified by a single key, has to be implemented
> with shared memory and multiple semaphores. (Under Windows)
I think you are confusing issues that are now private to the SysV sema
implementation with things that you really need to do for Windows.
Take a look at port/posix_sema.c for a less cluttered view of the
semantics you actually need to support. (I don't suppose there's any
chance that Gates & Co support POSIX semas, leaving you with no work?)
BTW, I have been able to test the named-semas variant of posix_sema.c
on OS X, and it works. I don't have access to any platforms that
support unnamed POSIX semas, which is too bad because that seems much
the preferable variant. Can anyone check it out?
regards, tom lane
PS: there's a trivial little test program in port/ipc_test.c; if you
want a "smoke test" that's simpler than a full Postgres build, try that.
Tom Lane wrote: > BTW, I have been able to test the named-semas variant of posix_sema.c > on OS X, and it works. I don't have access to any platforms that > support unnamed POSIX semas, which is too bad because that seems much > the preferable variant. Can anyone check it out? I did, and yes I was confused. Sorry. Your posix implementation assumes that only a single process will have access to the semaphore list for deletion is this correct? I guess I need to know how much access the child processes need to have to the internal control structures, none? Some? All? As I embark on my journey back to the dark side, here are my concerns for a native Windows PostgreSQL. I think it is a whole lot more than originally thought. (The Matrix: Do not try to implement the fork() that would be impossible, instead only try to realize the truth, there is no fork()) Cygwin does a lot of trickery to implement fork(), but it is not an OS level thing. Without fork() we would have to have a way to start a postgres backend and send it information about what it should be doing, and what it should be doing it with. With no fork(), information that would normally be copied on fork() is not copied. Therefore, we need to know what that information is and how to propagate it to the child process (under windows) Files, Windows does not have a native open,close,read,write ,lseek support. Yes, they have some notion of low I/O for compatibility, _open, _close, etc. but the flags and permissions are not identical. The low file API for Windows is CreateFile. Semaphores, and shared memory are easy enough (If have written it in different forms before), depending on the level of opaqueness to child processes. The voice in the back of my head, says we need to define what the portability issues are: process control (fork()/spawn() etc.) file operations (read, right, open, close, seek) IPC constructs (shared memory, semaphores) System interface (sync() etc) Any others? We should either use Apache's APR and augment it with semaphores, or come up with a doc which defines how these various things are handled. Obviously, it will grow as we find things that don't work.
Tom Lane wrote: > And no, I don't want to undo those changes. Especially not if the > only reason for it is to not have to use Cygwin on Windows. Most > of these changes made the startup code substantially simpler, > faster, and more reliable. Then I think the notion of a pure Windows version is dead in the water. Writing a fork()-like API for Windows is, of course, doable as evidenced by cygwin, and from a general theory seems like a pretty straight forward thing to do (with a few low level tricks of course) but the details are pretty scary. Has anyone done a profile of PostgreSQL running on a windows box and identified cygwin bottlenecks which we could augment with native code?
mlw <markw@mohawksoft.com> writes:
> I did, and yes I was confused. Sorry. Your posix implementation assumes that
> only a single process will have access to the semaphore list for deletion is
> this correct? I guess I need to know how much access the child processes need
> to have to the internal control structures, none? Some? All?
None. The postmaster creates the semas, and the postmaster deletes 'em.
The children only use them via the PGSemaphore structs they find in
shared memory. (The SysV implementation assumes that too btw.)
> With no fork(), information that would normally be copied on fork() is not
> copied. Therefore, we need to know what that information is and how to
> propagate it to the child process (under windows)
This will be a royal mess. Three or four years ago, when PG actually
did fork/exec to start a backend, we were careful to arrange to pass
everything the backend needed to know as command-line parameters (or
else keep it in shared memory). We have been busily breaking that
separation ever since we went over to fork-no-exec, however. In the
current scheme of things there is no chance whatever of a backend
working unless it inherits the global/static variables of the
postmaster.
And no, I don't want to undo those changes. Especially not if the
only reason for it is to not have to use Cygwin on Windows. Most
of these changes made the startup code substantially simpler,
faster, and more reliable.
regards, tom lane
On Tue, 7 May 2002, mlw wrote: > Tom Lane wrote: > > And no, I don't want to undo those changes. Especially not if the > > only reason for it is to not have to use Cygwin on Windows. Most > > of these changes made the startup code substantially simpler, > > faster, and more reliable. > > Then I think the notion of a pure Windows version is dead in the water. > Writing a fork()-like API for Windows is, of course, doable as evidenced > by cygwin, and from a general theory seems like a pretty straight > forward thing to do (with a few low level tricks of course) but the > details are pretty scary. How is Apache doing this? I believe they do allow the pre-forked model to work, so how are they getting around those limitations?
"Marc G. Fournier" wrote: > > On Tue, 7 May 2002, mlw wrote: > > > Tom Lane wrote: > > > And no, I don't want to undo those changes. Especially not if the > > > only reason for it is to not have to use Cygwin on Windows. Most > > > of these changes made the startup code substantially simpler, > > > faster, and more reliable. > > > > Then I think the notion of a pure Windows version is dead in the water. > > Writing a fork()-like API for Windows is, of course, doable as evidenced > > by cygwin, and from a general theory seems like a pretty straight > > forward thing to do (with a few low level tricks of course) but the > > details are pretty scary. > > How is Apache doing this? I believe they do allow the pre-forked model to > work, so how are they getting around those limitations? Apache and PostgreSQL are quite different in their requirements of shared memory. Apache (2.x) simply uses CreateProcess and passes duplicate file handles.
On Tue, 2002-05-07 at 15:31, Tom Lane wrote: > mlw <markw@mohawksoft.com> writes: > > In the current CVS directory, there is pgsql/src/backend/port directory. > > > I propose that this become a separate subproject and library. > > Right offhand, that seems a pointless exercise in relabeling code that's > going to be the same either way. What's the actual value? > > > The reason I want this is because the semaphore support, specifically > > multiple semaphores identified by a single key, has to be implemented > > with shared memory and multiple semaphores. (Under Windows) > > I think you are confusing issues that are now private to the SysV sema > implementation with things that you really need to do for Windows. > Take a look at port/posix_sema.c for a less cluttered view of the > semantics you actually need to support. (I don't suppose there's any > chance that Gates & Co support POSIX semas, leaving you with no work?) A quick google search acme up with http://sources.redhat.com/pthreads-win32/announcement.html -------------- Hannu
On Tue, 2002-05-07 at 15:31, Tom Lane wrote: > mlw <markw@mohawksoft.com> writes: > > In the current CVS directory, there is pgsql/src/backend/port directory. > > > I propose that this become a separate subproject and library. > > Right offhand, that seems a pointless exercise in relabeling code that's > going to be the same either way. What's the actual value? > > > The reason I want this is because the semaphore support, specifically > > multiple semaphores identified by a single key, has to be implemented > > with shared memory and multiple semaphores. (Under Windows) > > I think you are confusing issues that are now private to the SysV sema > implementation with things that you really need to do for Windows. > Take a look at port/posix_sema.c for a less cluttered view of the > semantics you actually need to support. (I don't suppose there's any > chance that Gates & Co support POSIX semas, leaving you with no work?) A quick google search came up with http://sources.redhat.com/pthreads-win32/announcement.html Unfortunately it seems to be the "wrong kind of free" software: Pthreads-win32 is free software, distributed under the GNU Lesser General Public License (LGPL). Or can we accept dependancies on LGPL libs for some ports. -------------- Hannu
On 7 May 2002, Hannu Krosing wrote: > On Tue, 2002-05-07 at 15:31, Tom Lane wrote: > > mlw <markw@mohawksoft.com> writes: > > > In the current CVS directory, there is pgsql/src/backend/port directory. > > > > > I propose that this become a separate subproject and library. > > > > Right offhand, that seems a pointless exercise in relabeling code that's > > going to be the same either way. What's the actual value? > > > > > The reason I want this is because the semaphore support, specifically > > > multiple semaphores identified by a single key, has to be implemented > > > with shared memory and multiple semaphores. (Under Windows) > > > > I think you are confusing issues that are now private to the SysV sema > > implementation with things that you really need to do for Windows. > > Take a look at port/posix_sema.c for a less cluttered view of the > > semantics you actually need to support. (I don't suppose there's any > > chance that Gates & Co support POSIX semas, leaving you with no work?) > > A quick google search came up with > > http://sources.redhat.com/pthreads-win32/announcement.html > > > Unfortunately it seems to be the "wrong kind of free" software: > > Pthreads-win32 is free software, distributed under the GNU Lesser > General Public License (LGPL). > > Or can we accept dependancies on LGPL libs for some ports. What someone installs on their Windows box is their problem ... doesn't mean we can't make use of it :) Its not something that will be part of the distribution itself, only something that needs to be availble :)
> -----Original Message----- > From: mlw [mailto:markw@mohawksoft.com] > Sent: Tuesday, May 07, 2002 7:03 AM > To: Tom Lane > Cc: Marc G. Fournier; PostgreSQL-development > Subject: Re: [HACKERS] OK, lets talk portability. > > > Tom Lane wrote: > > BTW, I have been able to test the named-semas variant of > posix_sema.c > > on OS X, and it works. I don't have access to any platforms that > > support unnamed POSIX semas, which is too bad because that > seems much > > the preferable variant. Can anyone check it out? > > I did, and yes I was confused. Sorry. Your posix > implementation assumes that > only a single process will have access to the semaphore list > for deletion is > this correct? I guess I need to know how much access the > child processes need > to have to the internal control structures, none? Some? All? > > As I embark on my journey back to the dark side, here are my > concerns for a > native Windows PostgreSQL. I think it is a whole lot more > than originally > thought. > > (The Matrix: Do not try to implement the fork() that would be > impossible, > instead only try to realize the truth, there is no fork()) > > Cygwin does a lot of trickery to implement fork(), but it is > not an OS level > thing. Without fork() we would have to have a way to start a > postgres backend > and send it information about what it should be doing, and > what it should be > doing it with. > > With no fork(), information that would normally be copied on > fork() is not > copied. Therefore, we need to know what that information is and how to > propagate it to the child process (under windows) > > Files, Windows does not have a native open,close,read,write > ,lseek support. > Yes, they have some notion of low I/O for compatibility, > _open, _close, etc. > but the flags and permissions are not identical. The low file > API for Windows > is CreateFile. > > Semaphores, and shared memory are easy enough (If have > written it in different > forms before), depending on the level of opaqueness to child > processes. > > > The voice in the back of my head, says we need to define what > the portability > issues are: > > process control (fork()/spawn() etc.) > file operations (read, right, open, close, seek) > IPC constructs (shared memory, semaphores) > System interface (sync() etc) > > Any others? > > We should either use Apache's APR and augment it with > semaphores, or come up > with a doc which defines how these various things are > handled. Obviously, it > will grow as we find things that don't work. A native port to Win32 has already been accomplished by several groups (including CONNX Solutions Inc., where I work). There is also one from Japan: http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html I saw some others when I looked around. Trying to implement fork() is a bad idea, I agree. We used CreateProcess instead to launch a new server. My idea of how portability ought to be accomplished is to leverage what others have done and use that. I have done a port of Pthreads to NT, which might be useful for a threaded version of the server, but I think a better approach would be to use an OS compatibility layer like ACE. ACE might also be useful for web servers and things of that nature. It may also be possible to create a server core from ACE that would outperform the PosgreSQL connection engine. JAWS (for instance) is a freely available web server that grotesqely outperforms Apache and the other free ones (which makes me puzzle about why JAWS is not more popular). Anyway, here is the ACE link: http://www.cs.wustl.edu/~schmidt/ACE.html
> -----Original Message----- > From: mlw [mailto:markw@mohawksoft.com] > Sent: Tuesday, May 07, 2002 7:44 AM > To: Tom Lane > Cc: Marc G. Fournier; PostgreSQL-development > Subject: Re: [HACKERS] OK, lets talk portability. > > > Tom Lane wrote: > > And no, I don't want to undo those changes. Especially not if the > > only reason for it is to not have to use Cygwin on Windows. Most > > of these changes made the startup code substantially simpler, > > faster, and more reliable. > > Then I think the notion of a pure Windows version is dead in > the water. Writing > a fork()-like API for Windows is, of course, doable as > evidenced by cygwin, and > from a general theory seems like a pretty straight forward > thing to do (with a > few low level tricks of course) but the details are pretty scary. > > Has anyone done a profile of PostgreSQL running on a windows > box and identified > cygwin bottlenecks which we could augment with native code? PW32: http://pw32.sourceforge.net/ has a better fork than Cygwin(), but it is still awful. Much better to start a new server with CreateProcess() on Win32 [absurdly faster]. The idea of fork() translation is to copy the heap and auto data. But the heap can split, so it isn't even really guaranteed to work. Quite frankly, fork() in Win32 is a very, very bad idea. Not just for efficiency reasons but also for reliability reasons.
"Marc G. Fournier" wrote: > > On 7 May 2002, Hannu Krosing wrote: > > > On Tue, 2002-05-07 at 15:31, Tom Lane wrote: > > > mlw <markw@mohawksoft.com> writes: > > > > In the current CVS directory, there is pgsql/src/backend/port directory. > > > > > > > I propose that this become a separate subproject and library. > > > > > > Right offhand, that seems a pointless exercise in relabeling code that's > > > going to be the same either way. What's the actual value? > > > > > > > The reason I want this is because the semaphore support, specifically > > > > multiple semaphores identified by a single key, has to be implemented > > > > with shared memory and multiple semaphores. (Under Windows) > > > > > > I think you are confusing issues that are now private to the SysV sema > > > implementation with things that you really need to do for Windows. > > > Take a look at port/posix_sema.c for a less cluttered view of the > > > semantics you actually need to support. (I don't suppose there's any > > > chance that Gates & Co support POSIX semas, leaving you with no work?) > > > > A quick google search acme up with > > > > http://sources.redhat.com/pthreads-win32/announcement.html > > Damn ... doesn't implement fork(), but does implement semaphores :) > Sooooo close :) Windows has semaphores, and looking at Tom's API, this is the least of our problems. If we can come up with a fork() free PostgreSQL, the rest is easy. We need to come up with a set of macros and function API that handle: Native file operations. Process control Shared memory, semaphores, and other IPC Sockets (Some Windows specific crap will need to be written, but the berkeley API is fine) System interface, sync(), fdatasync() and such.
On 7 May 2002, Hannu Krosing wrote: > On Tue, 2002-05-07 at 15:31, Tom Lane wrote: > > mlw <markw@mohawksoft.com> writes: > > > In the current CVS directory, there is pgsql/src/backend/port directory. > > > > > I propose that this become a separate subproject and library. > > > > Right offhand, that seems a pointless exercise in relabeling code that's > > going to be the same either way. What's the actual value? > > > > > The reason I want this is because the semaphore support, specifically > > > multiple semaphores identified by a single key, has to be implemented > > > with shared memory and multiple semaphores. (Under Windows) > > > > I think you are confusing issues that are now private to the SysV sema > > implementation with things that you really need to do for Windows. > > Take a look at port/posix_sema.c for a less cluttered view of the > > semantics you actually need to support. (I don't suppose there's any > > chance that Gates & Co support POSIX semas, leaving you with no work?) > > A quick google search acme up with > > http://sources.redhat.com/pthreads-win32/announcement.html Damn ... doesn't implement fork(), but does implement semaphores :) Sooooo close :) Semaphores --------------------------- sem_init sem_destroy sem_post sem_wait sem_trywait sem_timedwait sem_open (returns an error ENOSYS) sem_close (returns an error ENOSYS) sem_unlink (returns an error ENOSYS)
> -----Original Message----- > From: mlw [mailto:markw@mohawksoft.com] > Sent: Tuesday, May 07, 2002 7:58 AM > To: Marc G. Fournier > Cc: Tom Lane; PostgreSQL-development > Subject: Re: [HACKERS] OK, lets talk portability. > > > "Marc G. Fournier" wrote: > > > > On Tue, 7 May 2002, mlw wrote: > > > > > Tom Lane wrote: > > > > And no, I don't want to undo those changes. Especially > not if the > > > > only reason for it is to not have to use Cygwin on > Windows. Most > > > > of these changes made the startup code substantially simpler, > > > > faster, and more reliable. > > > > > > Then I think the notion of a pure Windows version is dead > in the water. > > > Writing a fork()-like API for Windows is, of course, > doable as evidenced > > > by cygwin, and from a general theory seems like a pretty straight > > > forward thing to do (with a few low level tricks of > course) but the > > > details are pretty scary. > > > > How is Apache doing this? I believe they do allow the > pre-forked model to > > work, so how are they getting around those limitations? > > Apache and PostgreSQL are quite different in their > requirements of shared > memory. Apache (2.x) simply uses CreateProcess and passes > duplicate file > handles. The way to make CreateProcess() work for PostgreSQL is very simple. By the time of the fork(), not much has been done. Some needed calculations can simply be stored into shared memory (which is trivial to implement). Some other tasks can simply be executed by the cloned process, exactly as they were executed in the server. Using fork() on Win32 is pointless, hopless, awful. Don't even think about it. It's a death warrant.
Translation from UNIX to Win32: http://www.byte.com/art/9410/sec14/art3.htm
A nice paper on one alternative to consider: http://www.infy.com/knowledge_capital/thought-papers/porting.pdf
On Tue, 2002-05-07 at 19:44, mlw wrote: > Tom Lane wrote: > > And no, I don't want to undo those changes. Especially not if the > > only reason for it is to not have to use Cygwin on Windows. Most > > of these changes made the startup code substantially simpler, > > faster, and more reliable. > > Then I think the notion of a pure Windows version is dead in the water. Writing > a fork()-like API for Windows is, of course, doable as evidenced by cygwin, and > from a general theory seems like a pretty straight forward thing to do (with a > few low level tricks of course) but the details are pretty scary. There is still another way - use threads. There you have of course the opposite problem - to determine what to _not_ share, but AFAIK this has been done already at least once. And there seems to be some consensus that doing things that would eventually make it easier to use threaded model will probably increase code quality in general. --------------- Hannu
Dann Corbit wrote: > A native port to Win32 has already been accomplished by several groups > (including CONNX Solutions Inc., where I work). > There is also one from Japan: > http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html > I saw some others when I looked around. It is the license issues, I think. > > Trying to implement fork() is a bad idea, I agree. We used > CreateProcess instead to launch a new server. That's my big issue, fork() is important to postgres because it assumes all the child's global and static variables will be a copy of what was in the parent, as well as system resources being cleaned up. Think about file handles, they have to be tracked and handled on a process level. The entire dynamic and static data memory area would have to be copied. Memory pointers allocated with "malloc()" would also have to be valid in the child, which means that the heap would have to be copied too. So, in short, the whole data area. I think abandoning cygwin will require more work than is justified, we would just end up rewriting it. So, if we are going to require cygwin or something like it, then I think we should spend our efforts to profile and optimize the cygwin version. I guess it comes down to the reason why we intend to get rid of the requirement of cygwin on Windows. If it is performance, we may be able to spot optimize the code under cygwin, and improve performance. If it is a license issue, then that is not a technical discussion, it is a legal one. Actions we take to remove a cygwin requirement, in the license case, are probably of limited technical merit, but of creating code (which probably already exists) for the PostgreSQL project with a license we can live with.
> mlw <markw@mohawksoft.com> writes: > > In the current CVS directory, there is pgsql/src/backend/port directory. > > BTW, I have been able to test the named-semas variant of posix_sema.c > on OS X, and it works. I don't have access to any platforms that > support unnamed POSIX semas, which is too bad because that seems much > the preferable variant. Can anyone check it out? > They are supported on QNX, so I will check it. They are also faster than named ones. -- igor
Dann Corbit wrote: > > > -----Original Message----- > > From: mlw [mailto:markw@mohawksoft.com] > > Sent: Tuesday, May 07, 2002 7:58 AM > > To: Marc G. Fournier > > Cc: Tom Lane; PostgreSQL-development > > Subject: Re: [HACKERS] OK, lets talk portability. > > > > > > "Marc G. Fournier" wrote: > > > > > > On Tue, 7 May 2002, mlw wrote: > > > > > > > Tom Lane wrote: > > > > > And no, I don't want to undo those changes. Especially > > not if the > > > > > only reason for it is to not have to use Cygwin on > > Windows. Most > > > > > of these changes made the startup code substantially simpler, > > > > > faster, and more reliable. > > > > > > > > Then I think the notion of a pure Windows version is dead > > in the water. > > > > Writing a fork()-like API for Windows is, of course, > > doable as evidenced > > > > by cygwin, and from a general theory seems like a pretty straight > > > > forward thing to do (with a few low level tricks of > > course) but the > > > > details are pretty scary. > > > > > > How is Apache doing this? I believe they do allow the > > pre-forked model to > > > work, so how are they getting around those limitations? > > > > Apache and PostgreSQL are quite different in their > > requirements of shared > > memory. Apache (2.x) simply uses CreateProcess and passes > > duplicate file > > handles. > > The way to make CreateProcess() work for PostgreSQL is very simple. > > By the time of the fork(), not much has been done. Some needed > calculations can simply be stored into shared memory (which is trivial > to implement). Some other tasks can simply be executed by the cloned > process, exactly as they were executed in the server. > > Using fork() on Win32 is pointless, hopless, awful. Don't even think > about it. It's a death warrant. Preaching to the choir my friend.
> -----Original Message----- > From: Hannu Krosing [mailto:hannu@tm.ee] > Sent: Tuesday, May 07, 2002 11:29 AM > To: mlw > Cc: Tom Lane; Marc G. Fournier; PostgreSQL-development > Subject: Re: [HACKERS] OK, lets talk portability. > > > On Tue, 2002-05-07 at 19:44, mlw wrote: > > Tom Lane wrote: > > > And no, I don't want to undo those changes. Especially not if the > > > only reason for it is to not have to use Cygwin on Windows. Most > > > of these changes made the startup code substantially simpler, > > > faster, and more reliable. > > > > Then I think the notion of a pure Windows version is dead > in the water. Writing > > a fork()-like API for Windows is, of course, doable as > evidenced by cygwin, and > > from a general theory seems like a pretty straight forward > thing to do (with a > > few low level tricks of course) but the details are pretty scary. > > There is still another way - use threads. > > There you have of course the opposite problem - to determine what to > _not_ share, but AFAIK this has been done already at least once. > > And there seems to be some consensus that doing things that would > eventually make it easier to use threaded model will probably increase > code quality in general. Unfortunately, it opens up another can of worms. With a fork() [or CreateProcess()] model, the newly spun binary can inherit a set of rights compatible to the user who attaches. With a threading model, everyone has the same set of rights. Easier to sleep at night if you know it is impossible for them to do damage to by performing an action they should not be able to do. Especially important if extension functions are added that spawn operating system tasks.
The requirement for Cygwin is a non-issue as I see it. Several groups have already done Win32 ports that do not require Cygwin. The company I work for is one example. The group in Japan: http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html is another. I saw some others besides these. In other words, you don't have to have Cygwin to run PostgreSQL under Win32 environments.
> Translation from UNIX to Win32: > http://www.byte.com/art/9410/sec14/art3.htm The problem here is that the strategies getting sold aren't "How Do We Make it Portable?" ones, but rather "How do we port it to Windows, and throw away the Unix version?" The "neat technologies" are _not_ portability ventures, but rather porting ventures, one way trips down the "Richmond Highway." To have something that will truly be portable, it can't directly use fork(). It has to use [something else] which gets translated at compile time to fork(), on Unix, and presumably to CreateProcess() on Windows. It's probably possible; I doubt it's simple nor much of an improvement. And it begs the question: Is it really greatly advantageous to invoke a lot of "breakage" on existing code just to get the engine to work on Windows, when "Windows 2004" will probably have some built-in DBMS technology that tries to kill off _all_ Windows-based DBMSes that don't come from Microsoft? -- (reverse (concatenate 'string "gro.gultn@" "enworbbc")) http://www.cbbrowne.com/info/rdbms.html It is better to be a smart ass than a dumb ass. -- (concatenate 'string "chris" "@cbbrowne.com") http://www.cbbrowne.com/info/linuxdistributions.html "The primary difference between computer salesmen and used car salesmen is that used car salesmen know when they're lying to you."
Just a note: Apache 2.0.36 just released and this is in the release notes: *) Deprecated the apr_lock.h API. Please see the following files for the improved thread and process locking and signaling: apr_proc_mutex.h, apr_thread_mutex.h, apr_thread_rwlock.h, apr_thread_cond.h, and apr_global_mutex.h. [AaronBannert] Chris > > By the time of the fork(), not much has been done. Some needed > > calculations can simply be stored into shared memory (which is trivial > > to implement). Some other tasks can simply be executed by the cloned > > process, exactly as they were executed in the server. > > > > Using fork() on Win32 is pointless, hopless, awful. Don't even think > > about it. It's a death warrant. > > Preaching to the choir my friend.
Le Mardi 7 Mai 2002 22:41, mlw a écrit : > I think abandoning cygwin will require more work than is justified, we > would just end up rewriting it. So, if we are going to require cygwin or > something like it, then I think we should spend our efforts to profile and > optimize the cygwin version. > > I guess it comes down to the reason why we intend to get rid of the > requirement of cygwin on Windows. If it is performance, we may be able to > spot optimize the code under cygwin, and improve performance. If it is a > license issue, then that is not a technical discussion, it is a legal one. > Actions we take to remove a cygwin requirement, in the license case, are > probably of limited technical merit, but of creating code (which probably > already exists) for the PostgreSQL project with a license we can live with. There is other issues : 1) Cygwin installation. Presently, Cygwin installer is a nice toy but it is primarily designed for hackers. In order to install PostgreSQL, you need to install a minimum set of packages. As no real dependency between packages exist, a newbee will not know which packages should be downloaded and which should not. Also, Cygwin installer does not allow the automatic installation of PostgreSQL within a service. The result is that newbees eather download ***all*** Cygwin packages or simply say no. Furthermore, after installation, people are facing another issue which is the Unix world. Users have a hard time understanding that PostgreSQL configuration is stored in /var/lib/pgsql/... So my personal opinion is that if PostgreSQL relies on the present Cygwin version, it has no chance to get a standard solution under Windows. 2) Cygwin static implementation When I contacted Cygwin team, they said there used to be a static version of Cygwin which is no longer maintained. They also told me there was little work to get it working again. Maybe you could fork a Cygwin static version into a dll. This may sound as a ***bizarre*** idea, don't flame me, but they PostgreSQL would only depend on this dll with static Cygwin built-in. 3) Existing version of PostgreSQL under Windows Did anyone test http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html Cheers, Jean-Michel POURE
> -----Original Message----- > From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr] > Sent: 08 May 2002 09:37 > To: mlw; Dann Corbit > Cc: PostgreSQL-development > Subject: Re: OK, lets talk portability. > > There is other issues : > > 1) Cygwin installation. > > Presently, Cygwin installer is a nice toy but it is primarily > designed for > hackers. In order to install PostgreSQL, you need to install > a minimum set of > packages. As no real dependency between packages exist, a > newbee will not > know which packages should be downloaded and which should > not. Also, Cygwin > installer does not allow the automatic installation of > PostgreSQL within a > service. > > The result is that newbees eather download ***all*** Cygwin > packages or simply > say no. Furthermore, after installation, people are facing > another issue > which is the Unix world. Users have a hard time understanding > that PostgreSQL > configuration is stored in /var/lib/pgsql/... > > So my personal opinion is that if PostgreSQL relies on the > present Cygwin > version, it has no chance to get a standard solution under Windows. Agreed. I develop pgAdmin using cygwin/postgresql on my laptop and quite frankly it's a pain in the neck. I did notice when playing with MySQL recently that it appears to use Cygwin, though *only* the .dll, there is no installation of Cygwin required. Perhaps if we could get to roughly that stage it would be good. Of course we'd also need a few things from /bin like sh for example. If we can get it to this stage then I'm sure Jean-Michel and I could come up with a nice installer that will allow us to keep the GPL & BSD code nicely separate on a swerver somewhere & still allow an automated download/install... > 3) Existing version of PostgreSQL under Windows > Did anyone test > http://hp.vector.co.jp/authors/VA023283/Postgr> eSQLe.html Downloaded it but haven't played yet (blame it on a cranky Exchange server!). Regards, Dave.
On Thu, 2002-05-09 at 09:12, Dave Page wrote: > > Agreed. I develop pgAdmin using cygwin/postgresql on my laptop and quite > frankly it's a pain in the neck. I did notice when playing with MySQL > recently that it appears to use Cygwin, though *only* the .dll, there is > no installation of Cygwin required. Perhaps if we could get to roughly > that stage it would be good. Of course we'd also need a few things from > /bin like sh for example. Are you sure sh and friends are absolutely needed ? I'm sure we can replace most scripts with .bat files or just do without them (tell peole to use CREATE DATABSE instead of createdb, etc.) And instead of initdb we could just install ready-made $PGSQL/data directory. ----------- Hannu
> -----Original Message----- > From: Hannu Krosing [mailto:hannu@tm.ee] > Sent: 09 May 2002 09:57 > To: Dave Page > Cc: jm.poure@freesurf.fr; mlw; Dann Corbit; PostgreSQL-development > Subject: Re: [HACKERS] OK, lets talk portability. > > > On Thu, 2002-05-09 at 09:12, Dave Page wrote: > > > > Agreed. I develop pgAdmin using cygwin/postgresql on my laptop and > > quite frankly it's a pain in the neck. I did notice when > playing with > > MySQL recently that it appears to use Cygwin, though *only* > the .dll, > > there is no installation of Cygwin required. Perhaps if we > could get > > to roughly that stage it would be good. Of course we'd also > need a few > > things from /bin like sh for example. > > Are you sure sh and friends are absolutely needed ? > > I'm sure we can replace most scripts with .bat files or just > do without them (tell peole to use CREATE DATABSE instead of > createdb, etc.) > > And instead of initdb we could just install ready-made > $PGSQL/data directory. Yes, we could do that quite easily in which case only the .dll should be required. Probably the only required scripts would be: pg_dumpall initlocation I have doubts about how easily initlocation could be rewritten as a batch file though... Regards, Dave.
Le Jeudi 9 Mai 2002 09:12, Dave Page a écrit : > If we can get it to this stage then I'm sure Jean-Michel and I could > come up with a nice installer that will allow us to keep the GPL & BSD > code nicely separate on a swerver somewhere & still allow an automated > download/install... This would be quite easy. But the problem is that we might need to rename Cygwin.dll in order to avoid conflicts. It may become a maintenance nightmare. This will not stop Cygwin from provinding PostgreSQL neither. To my mind, the solution is to deliver all software needed (native Apache, native Python, Native OpenOffice, Cygwin layer, Dev-C++, pgAdmin2, Cygwin-KDE) within a SINGLE installer. See my previous mails. Work is time-consuming. If I have to spend time on a project, this will be for getting rid of Microsoft hegemony, not the less. Cheers, Jean-Michel
On Thursday 09 May 2002 04:56 am, Hannu Krosing wrote: [snip other good ideas....] > And instead of initdb we could just install ready-made $PGSQL/data > directory. From experience with the RPMset I can tell you that this is a bad idea, and it comes down to one word: upgrades. Now if the installation location is _versioned_ we might can talk of a pre-populated $PGDATA. I'm taking a really hard look right now at versioned installation locations for the RPMset -- you can then have more than one version installed at a time, and even running at one time if you're careful. I haven't implemented it yet, but I am taking a long hard look at what I would have to do in order to make it work. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11