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.
