Re: OK, lets talk portability.

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.