Обсуждение: Re: Issues tangential to win32 support
> -----Original Message----- > From: Hannu Krosing [mailto:hannu@tm.ee] > Sent: Thursday, May 09, 2002 12:10 PM > To: Jan Wieck > Cc: Scott Marlowe; PostgreSQL-development > Subject: Re: [HACKERS] Issues tangential to win32 support > > > On Thu, 2002-05-09 at 22:51, Jan Wieck wrote: > > Scott Marlowe wrote: > > > There are some issues that the whole idea of a win32 port > should bring up. > > > One of them is whether or not postgresql should be rewritten as a > > > multi-threaded app. > > > > Please, don't add this one to it. > > > > I'm all for the native Windows port, yes, but I've discussed > > the multi-thread questions for days at Great Bridge, then > > again with my new employer, with people on shows and whatnot. > > > > Anything in the whole backend is designed with a multi- > > process model in mind. You'll not do that in any reasonable > > amount of time. > > IIRC you are replying to the man who _has_ actually don this ? > > Perhaps using an unreasonable amount of time but still ... :) It took a few hundred man hours to do it. I see the whole Win32 port as a non issue. Several parties have already completed it (including the place where I work -- CONNX Solutions Inc.). If we did not do it or all parties who already did it were hit by a comet or something, someone else would accomplish it. It isn't trivial but it isn't impossible either. If a need is large enough, someone will manage it. The need is large enough. Ergo... Here are some other things related: A ready to go Win32 PosgreSQL package: http://www.dbexperts.net/postgresql An open source project to productize PostgreSQL for Windows (has gone nowhere so far): http://gborg.postgresql.org/project/winpackage/projdisplay.php A native Win32 port accomplished by a Japanese Group: http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html If you look under the "Gists for Patch" it contains exactly the same tasks that CONNX Solutions Inc. had to accomplish in every case.
Dann Corbit wrote: > It took a few hundred man hours to do it. I see the whole Win32 port as > a non issue. Several parties have already completed it (including the > place where I work -- CONNX Solutions Inc.). If we did not do it or all > parties who already did it were hit by a comet or something, someone > else would accomplish it. It isn't trivial but it isn't impossible > either. If a need is large enough, someone will manage it. The need is > large enough. Ergo... > > Here are some other things related: > > A ready to go Win32 PosgreSQL package: > http://www.dbexperts.net/postgresql > > An open source project to productize PostgreSQL for Windows (has gone > nowhere so far): > http://gborg.postgresql.org/project/winpackage/projdisplay.php > > A native Win32 port accomplished by a Japanese Group: > http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html > If you look under the "Gists for Patch" it contains exactly the same > tasks that CONNX Solutions Inc. had to accomplish in every case. These packages are based upon cygwin. Problems with cygwin: (1) GNU license issues. (2) Does not work well with anti-virus software (3) Since OS level copy-on-write is negated, process creation is much slower. (4) Since OS level copy on write is negated, memory that otherwise would not be allocated to the process is forced to ba allocated when the parent process data is copied.
> -----Original Message----- > From: mlw [mailto:markw@mohawksoft.com] > Sent: Thursday, May 09, 2002 2:41 PM > To: Dann Corbit > Cc: PostgreSQL-development > Subject: Re: Issues tangential to win32 support > > > Dann Corbit wrote: > > It took a few hundred man hours to do it. I see the whole > Win32 port as > > a non issue. Several parties have already completed it > (including the > > place where I work -- CONNX Solutions Inc.). If we did not > do it or all > > parties who already did it were hit by a comet or something, someone > > else would accomplish it. It isn't trivial but it isn't impossible > > either. If a need is large enough, someone will manage it. > The need is > > large enough. Ergo... > > > > Here are some other things related: > > > > A ready to go Win32 PosgreSQL package: > > http://www.dbexperts.net/postgresql > > > > An open source project to productize PostgreSQL for Windows > (has gone > > nowhere so far): > > http://gborg.postgresql.org/project/winpackage/projdisplay.php > > > > A native Win32 port accomplished by a Japanese Group: > > http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html > > If you look under the "Gists for Patch" it contains exactly the same > > tasks that CONNX Solutions Inc. had to accomplish in every case. > > These packages are based upon cygwin. Problems with cygwin: > > (1) GNU license issues. > (2) Does not work well with anti-virus software > (3) Since OS level copy-on-write is negated, process creation > is much slower. > (4) Since OS level copy on write is negated, memory that > otherwise would not be > allocated to the process is forced to ba allocated when the > parent process data > is copied. Our package avoids Cygwin altogether. We wrote our own POSIX layer from scratch, and we junked fork() for CreateProcess() {and inserted copious: #ifdef ICKY_WIN32_KLUDGE /* our code goes here */ #else /* Standard UNIX code goes here */ #endif It's complete, and it performs like the burning blue blazes. We have run the full PostgreSQL test suite to completion with success. However, before we release any SQL tool, we have our own test suite with tens of thousands of tests to perform. Hence, we won't have a release until June at the earliest. I think the Japanese one also does not use Cygwin (but I have not tried installing it yet).
Dann Corbit wrote:
> Our package avoids Cygwin altogether. We wrote our own POSIX layer from
> scratch, and we junked fork() for CreateProcess() {and inserted copious:
> #ifdef ICKY_WIN32_KLUDGE
> /* our code goes here */
> #else
> /* Standard UNIX code goes here */
> #endif
OK, what sorts of things did you do in your ICKY_WIN32_KLUDGE? Were they ever
migrated back into the main tree? Did you simulate fork() or a stand-alone?
I know Windows very well, but I have thus far remained ignorant of PostgreSQL
internals.
>
> It's complete, and it performs like the burning blue blazes. We have
> run the full PostgreSQL test suite to completion with success. However,
> before we release any SQL tool, we have our own test suite with tens of
> thousands of tests to perform. Hence, we won't have a release until
> June at the earliest.
>
> I think the Japanese one also does not use Cygwin (but I have not tried
> installing it yet).
The japanese site claims cygwin.
> -----Original Message-----
> From: mlw [mailto:markw@mohawksoft.com]
> Sent: Thursday, May 09, 2002 2:56 PM
> To: Dann Corbit
> Cc: PostgreSQL-development
> Subject: Re: Issues tangential to win32 support
>
>
> Dann Corbit wrote:
> > Our package avoids Cygwin altogether. We wrote our own
> POSIX layer from
> > scratch, and we junked fork() for CreateProcess() {and
> inserted copious:
> > #ifdef ICKY_WIN32_KLUDGE
> > /* our code goes here */
> > #else
> > /* Standard UNIX code goes here */
> > #endif
>
> OK, what sorts of things did you do in your
> ICKY_WIN32_KLUDGE? Were they ever
> migrated back into the main tree? Did you simulate fork() or
> a stand-alone?
I explained it in another mail.
We had quite a few changes we had to make (several hundred man-hours,
about half of which was the POSIX layer and the precise time routines).
No sense trying to simulate fork() -- it stinks on Win32. The Cygwin
and PW32 implementations of fork() are dogs. Smarter folks than us
tried it and failed miserably. Why reinvent a broken wheel? We use
create process and our own startup code. Our version is competitive
with fork() on Linux for spawning tasks and in general the queries run
considerably faster.
> I know Windows very well, but I have thus far remained
> ignorant of PostgreSQL
> internals.
On Fri, 2002-05-10 at 02:33, Dann Corbit wrote: > > It took a few hundred man hours to do it. About 2-8 weeks for one full time programmer ? > I see the whole Win32 port as > a non issue. Several parties have already completed it (including the > place where I work -- CONNX Solutions Inc.). If we did not do it or all > parties who already did it were hit by a comet or something, someone > else would accomplish it. It isn't trivial but it isn't impossible > either. If a need is large enough, someone will manage it. The need is > large enough. Ergo... Do you know which of these run ((reasonably) well) on win9x ? > Here are some other things related: > > A ready to go Win32 PosgreSQL package: > http://www.dbexperts.net/postgresql Perhaps we should back up and let dbexperts et.al. recover their costs and after that repent and commit changes back to main tree ;) ## insert a little ad-hominem attack to everyone objecting a native ## win32 port as owning stock in some win32-pg-selling company BTW, do they have an evaluation version or do they think that people would in that case evaluate on win32 and then buy a cheap linux box for $495.- :) -------------------- Hannu
> -----Original Message-----
> From: mlw [mailto:markw@mohawksoft.com]
> Sent: Thursday, May 09, 2002 2:56 PM
> To: Dann Corbit
> Cc: PostgreSQL-development
> Subject: Re: Issues tangential to win32 support
>
>
> Dann Corbit wrote:
> > Our package avoids Cygwin altogether. We wrote our own
> POSIX layer from
> > scratch, and we junked fork() for CreateProcess() {and
> inserted copious:
> > #ifdef ICKY_WIN32_KLUDGE
> > /* our code goes here */
> > #else
> > /* Standard UNIX code goes here */
> > #endif
>
> OK, what sorts of things did you do in your
> ICKY_WIN32_KLUDGE? Were they ever
> migrated back into the main tree? Did you simulate fork() or
> a stand-alone?
>
> I know Windows very well, but I have thus far remained
> ignorant of PostgreSQL
> internals.
>
> >
> > It's complete, and it performs like the burning blue
> blazes. We have
> > run the full PostgreSQL test suite to completion with
> success. However,
> > before we release any SQL tool, we have our own test suite
> with tens of
> > thousands of tests to perform. Hence, we won't have a release until
> > June at the earliest.
> >
> > I think the Japanese one also does not use Cygwin (but I
> have not tried
> > installing it yet).
>
> The japanese site claims cygwin.
This is not correct. (Fortunately, we have someone here who reads and
writes Japanese).
At any rate, it is a complete, native implementation of PostgreSQL
without any need for Cygwin.
Just to be sure, I did a "depends" on each of the binaries and none of
them use Cywin.
So the Japanese site did exactly the same thing that we did.
Here are bitmaps showing the complete dependency trees of both the
Japanese efforts and ours as well:
Us:
ftp://cap.connx.com/pub/chess-engines/new-approach/connx.bmp
Japanese:
ftp://cap.connx.com/pub/chess-engines/new-approach/japanese.bmp
No Cygwin in sight in either case.
Dann Corbit wrote: http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html Mentions cygwin, am I misunderstanding? Does not matter, the issue is that you guys said you did it. OK, have you been able to bring the changed back into the main source tree? (Are you not trying?)
> -----Original Message----- > From: mlw [mailto:markw@mohawksoft.com] > Sent: Thursday, May 09, 2002 3:34 PM > To: Dann Corbit > Cc: PostgreSQL-development > Subject: Re: Issues tangential to win32 support > > > Dann Corbit wrote: > http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html > > Mentions cygwin, am I misunderstanding? > > Does not matter, the issue is that you guys said you did it. > OK, have you been > able to bring the changed back into the main source tree? > (Are you not trying?) I am not enrolled in the CVS project, and don't even know how to use it. We use "Visual Source Safe" here -- really an icky tool but at least everyone here knows it. There is some debate here as to whether to keep the changes private or to turn them back to the project. Not sure how it will turn out. I am not sure that the project would want them anyway, since the represent some pretty major surgery and impact the readability of the code in a quite adverse way. At any rate, the Japanese version appears to be released. In fact, I have downloaded the whole project and gave it a spin. It is actually very nice. If you just need to use something for right now, why not go with that version? In any case, there is simply no way possible that anything will ever escape from here before June at the absolute earliest (full regression test is company policy).
Dann Corbit wrote: > I am not enrolled in the CVS project, and don't even know how to use it. > We use "Visual Source Safe" here -- really an icky tool but at least > everyone here knows it. Source Safe? Yikes. I haven't used that in a long time. > > There is some debate here as to whether to keep the changes private or > to turn them back to the project. Not sure how it will turn out. > > I am not sure that the project would want them anyway, since the > represent some pretty major surgery and impact the readability of the > code in a quite adverse way. I hear you on that. I have tons of code that has #ifdef GCC and #ifdef WIN32 in lots of places. Obviously you wrap what you can in macros and/or functions, but you can't do that 100% the time. Some people REALLY hate #ifdef/#endif and view them as a bad coding practice. Others, like myself, view them as a proper usage of the language constructs and judicious use of them actually help the developer understand the code better. > > At any rate, the Japanese version appears to be released. In fact, I > have downloaded the whole project and gave it a spin. It is actually > very nice. If you just need to use something for right now, why not go > with that version? I have no desire for a Windows version for myself, but I see the need for it. > > In any case, there is simply no way possible that anything will ever > escape from here before June at the absolute earliest (full regression > test is company policy). ok
> Dann Corbit wrote: > http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html > > Mentions cygwin, am I misunderstanding? Are you talking about following in the page? ---------------------------------------------------------------- * Notice: Based upon the GNU-cygwin, there is a version that works similar to the Unix-compatible operability. Tanida-san Web site is supporting this environment in Japanese. ---------------------------------------------------------------- It cleary refers to another work. -- Tatsuo Ishii