Claudio Natoli wrote:
> * Users already have a postgres solution for Win32. It is called
Cygwin w/
> cygipc. Sure, it is not the most stable solution, but, IMHO, that's
not
> what
> prevents people from using it; it is the need to install yet-another
bit
> of
> software to support Postgres. If we want to take the fight to MySQL,
again
> IMNSHO, this is not the way to proceeed.
I don't use it because I don't feel it is stable and the write
performance is not very good. Also, the ipc-daemon sometimes crashes
which is a big PITA. Also, some months back Justin Clift made a proof
of concept installer for cygwin based version.
It's unclear if such an installer could be made for sfu.
> * We are close to a Win32 port already. When the last patch is
applied,
> there are only a few minor things to resolve (some "hard-coded"
directory
> issues, whitespaces in directory names), and two larger ones... namely
> sync
> + signals. We've believe we are onto a workable solution to signals,
and I
> personally think the sync issue isn't a big deal.
I agree with you very much on this point. At the very least, we should
run both version side by side and make an objective comparison.
> At this point, I can't see that this is anything other than a
distraction.
> Perhaps in the future, but well, I can't see how we'd justify it short
of
> being unable to suitably "fake" signals (unlikely), or being able to
prove
> (and that is prove, not assume) that sync performance would greatly
> improve
> under SFU.
Admittedly I didn't give full consideration to the installation issues
of the SFU version. The performance of course is a big question mark;
it could be much better or much worse than a hand coded port. Plus, the
win32 is so close to completion I can almost taste it... :)
Also, even if sync() and other I/O calls are a problem, the win32 API
has a lot of I/O optimization potential so that is not necessarily a
long term problem.
Merlin