"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()?
