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.
