Win32 port patches submitted

Jan Wieck writes:

I just submitted the patches for the native Win32 port of v7.2.1 on the
patches mailing list.

I'm concerned that you are adding all these *.dsp files for build process
control. This is going to be a burden to maintain. Everytime someone
changes an aspect of how a file is built the Windows port needs to be
fixed. And since the tool that operates on these files is probably not
freely available this will be difficult. I don't see a strong reason not
to stick with good old configure; make; make install. You're already
requiring various Unix-like tools, so you might as well require the full
shell environment. A lot of the porting aspects such as substitute
implemenations of the C library functions could be handled nearly for free
using the existing infrastructure and this whole patch would become much
less intimidating.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

I don't see a strong reason not
to stick with good old configure; make; make install. You're already
requiring various Unix-like tools, so you might as well require the full
shell environment.

Indeed. I think the goal here is to have a port that *runs* in native
Windows; but I see no reason not to require Cygwin for *building* it.

regards, tom lane

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

I don't see a strong reason not
to stick with good old configure; make; make install. You're already
requiring various Unix-like tools, so you might as well require the full
shell environment.

Indeed. I think the goal here is to have a port that *runs* in native
Windows; but I see no reason not to require Cygwin for *building* it.

Agreed.

We focused on porting the programs. The goal was to have PostgreSQL
running native on Win32 for a user. Having a nice and easy maintainable
cross platform config, build and test environment for the developers is
definitely something that still needs to be done (hint, hint).

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

I would back keeping the windows specific files, and if anything moving the
code away from using the UNIX like programs. My reasoning is that the more
unix tools you use for compiling, the less likley you are to attract
existing windows-only developers to work on the code. I see the Win32 patch
as a great oppertunity to attract more eyes to the code, and don't want the
oppertunity to be lost because of the build requirements.

Al.

----- Original Message -----
From: "Peter Eisentraut" <peter_e@gmx.net>
To: "Jan Wieck" <JanWieck@Yahoo.com>
Cc: "Postgres development" <pgsql-hackers@postgresql.org>
Sent: Tuesday, January 21, 2003 5:40 PM
Subject: [mail] Re: [HACKERS] Win32 port patches submitted

On Tue, 21 Jan 2003, Al Sutton wrote:

I would back keeping the windows specific files, and if anything moving the
code away from using the UNIX like programs. My reasoning is that the more
unix tools you use for compiling, the less likley you are to attract
existing windows-only developers to work on the code. I see the Win32 patch
as a great oppertunity to attract more eyes to the code, and don't want the
oppertunity to be lost because of the build requirements.

The problem is that when either side (unix developer or windows developer)
wants to do anything that changes the build procedure, the other side
breaks until someone makes the appropriate changes on the other build.
Unless some committer is going to commit to looking over patches to dsp
files and making makefile changes and vice versa or we were to require
that anyone that wants to change build procedure must make both sets of
changes, I'd think this is going to be a mess. And in the latter case, I
think you're going to lose developers as well.

"Al Sutton" <al@alsutton.com> writes:

I would back keeping the windows specific files, and if anything moving the
code away from using the UNIX like programs. My reasoning is that the more
unix tools you use for compiling, the less likley you are to attract
existing windows-only developers to work on the code.

You think we should drive away our existing unix developers in the mere
hope of attracting windows developers? Sorry, it isn't going to happen.

regards, tom lane

Tom Lane wrote:

"Al Sutton" <al@alsutton.com> writes:

I would back keeping the windows specific files, and if anything moving the
code away from using the UNIX like programs. My reasoning is that the more
unix tools you use for compiling, the less likley you are to attract
existing windows-only developers to work on the code.

You think we should drive away our existing unix developers in the mere
hope of attracting windows developers? Sorry, it isn't going to happen.

A compromise is a solution that makes all sides equally unhappy ... so
we should convert our build environment to ANT? Hey, just kidding ;-)

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Problem is, nobody builds packages on windows anyway. They just all
download the binary a guy (usually literally "one guy") built. So, let's
just make sure that one guy has cygwin loaded on his machine and we'll be
all set. </tougue in cheek>

Sorry, couldn't help myself...Seriously, it's a cultural thing, I wouldn't
plan on a mighty hoard of windows database developers who are put off by
loading cygwin. I do wonder what the requirements are for building
commercial db's that run on unix and windows. I imagine they are
similarly off-putting if it were an option.

On Tue, 21 Jan 2003, Al Sutton wrote:

Mingw and mingw-ported tools ? That's a nice small and cozy unix-like
envoronment on tom of Windows. Add it emacs, and windoww becomes almost
tolerable ...

Emmanuel Charpentier

[ Back to lurking ... ]

Brian Bruns wrote:

Emmanuel Charpentier wrote:

Mingw and mingw-ported tools ? That's a nice small and cozy unix-like
envoronment on tom of Windows. Add it emacs, and windoww becomes almost
tolerable ...

How good is the debugging support under mingW? Is it at least comparable
to using gdb under unix? If not, you might find yourself all of the
sudden out in cold ...

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

-----Original Message-----
From: Jan Wieck [mailto:JanWieck@Yahoo.com]
Sent: Tuesday, January 21, 2003 4:04 PM
To: Emmanuel Charpentier
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [mail] Re: Win32 port patches submitted

Emmanuel Charpentier wrote:

Mingw and mingw-ported tools ? That's a nice small and cozy

unix-like

envoronment on tom of Windows. Add it emacs, and windoww becomes
almost tolerable ...

How good is the debugging support under mingW? Is it at least
comparable to using gdb under unix? If not, you might find
yourself all of the sudden out in cold ...

GDB works fine. Some of the other tools don't work right (e.g. sed is
broken).

Brian Bruns wrote:

Problem is, nobody builds packages on windows anyway. They just all
download the binary a guy (usually literally "one guy") built. So, let's
just make sure that one guy has cygwin loaded on his machine and we'll be
all set. </tougue in cheek>

Correct.
I wonder why we need a Windows port. I think it is more pain than sense.
In case of Windows I'd rely on a binary distribution and a piece of
documentation telling how the source can be built. I don't expect many
people to do it. Usually Open Source guys run *NIX

Sorry, couldn't help myself...Seriously, it's a cultural thing, I wouldn't
plan on a mighty hoard of windows database developers who are put off by
loading cygwin. I do wonder what the requirements are for building
commercial db's that run on unix and windows. I imagine they are
similarly off-putting if it were an option.

In case of SAP DB they use a tool kit for building

http://www.sapdb.org/develop/sap_db_development.htm

It is truly painful to build it - even on UNIX (I haven't tried on
Windows and I won't try in the future).
As far as I have seen it throughs millions of compiler warnings.

Regards,
Hans

--
*Cybertec Geschwinde u Schoenig*
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/1/913 68 09; +43/664/233 90 75
www.postgresql.at <http://www.postgresql.at&gt;, cluster.postgresql.at
<http://cluster.postgresql.at&gt;, www.cybertec.at
<http://www.cybertec.at&gt;, kernel.cybertec.at <http://kernel.cybertec.at&gt;

-----Original Message-----
From: Hans-Jürgen Schönig [mailto:postgres@cybertec.at]
Sent: Tuesday, January 21, 2003 10:54 PM
To: Brian Bruns; pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Win32 port patches submitted

Brian Bruns wrote:

Problem is, nobody builds packages on windows anyway. They just all
download the binary a guy (usually literally "one guy")

built. So, let's

just make sure that one guy has cygwin loaded on his machine

and we'll be

all set. </tougue in cheek>

Correct.
I wonder why we need a Windows port.

Maybe because most of the machines in the world (by a titanic landslide) are Windoze boxes.

I think it is more pain
than sense. In case of Windows I'd rely on a binary
distribution and a piece of
documentation telling how the source can be built.

Sounds like a Windows port to me. How is this "Windows build" going to be created without a "Windows port"?

I don't
expect many
people to do it. Usually Open Source guys run *NIX

Taken a poll lately?

Sorry, couldn't help myself...Seriously, it's a cultural thing, I
wouldn't
plan on a mighty hoard of windows database developers who

are put off by

loading cygwin. I do wonder what the requirements are for building
commercial db's that run on unix and windows. I imagine they are
similarly off-putting if it were an option.

In case of SAP DB they use a tool kit for building

http://www.sapdb.org/develop/sap_db_development.htm

It is truly painful to build it - even on UNIX (I haven't tried on
Windows and I won't try in the future).
As far as I have seen it throughs millions of compiler warnings.

It was simple to build. And if you don't want to build it, they have binary distributions. I have SAP/DB running on this machine (along with SQL*Server, PostgreSQL, DB/2, Oracle, Firebird and a few others) SAP DB is or can be used for SAP (basically, it's a port of Adabas). That makes it kind of important, for obvious reasons.

Jan Wieck wrote:

Emmanuel Charpentier wrote:

Mingw and mingw-ported tools ? That's a nice small and cozy unix-like
envoronment on tom of Windows. Add it emacs, and windoww becomes almost
tolerable ...

How good is the debugging support under mingW? Is it at least comparable
to using gdb under unix? If not, you might find yourself all of the
sudden out in cold ...

gdb has been ported to mingw. There even exist some interfaces to
graphical IDEs (while I don't really care for that).

Another point : this environment is 100% free. You don't have to use
proprietary tools. This might be a point in some environments.

Emmanuel Charpentier

Dann Corbit wrote:

[ ... ]

GDB works fine. Some of the other tools don't work right (e.g. sed is
broken).

Recent fixes exist, but I didn't check all of them. WorksForMe(TM), but my
projects are *much* simpler ...

Emmanuel Charpentier

http://www.janwieck.net/win32_port/notes.win32-ports.txt
How to compile this Win32 port
1) Requirements and 1-time settings:
1.1) Visual C++
You need VC++ 6.0 on ServicePack 5.

Oooh no, not MS stuff plz :(
Dev-Cpp is cool open source IDE, tha using a mingw port of gcc.
http://www.bloodshed.net/

----- Original Message -----
From: "Jan Wieck" <JanWieck@Yahoo.com>
To: "Emmanuel Charpentier" <charpent@bacbuc.dyndns.org>
Cc: <pgsql-hackers@postgresql.org>
Sent: Wednesday, January 22, 2003 1:03 AM
Subject: Re: [HACKERS] [mail] Re: Win32 port patches submitted

tom lane writes:

You think we should drive away our existing unix developers
in the mere hope of attracting windows developers? Sorry, it
isn't going to happen.

Tom brings up a good point, that changes to support Windows should not
add to the tasks of those who are doing the bulk of the work on Unixen.

I don't think, however, that this necessarily means that having Windows
developers use Cygwin is the right solution. We need to come up with a
way to support Windows Visual C++ projects without adding work to the
other developers.

I believe this is possible and have outlined some ways at the end, but
first some rationale:

One of the biggest benefits to Open Source projects is the ability to
get in there and debug/fix problems using the source. PostgreSQL will
lose out to lesser DBs if there is no easy way to build and DEBUG the
source on Windows. This is true whether one admits that Windows sucks or
not.

A developer faced with the decision of choosing:

A) a system that has a native Windows Visual C++ project that runs and
compiles the release with no work.

B) a system that requires learning a new way of building, new tools, new
who knows what else.

will always choose A unless there is a very compelling reason to choose
B. There are plenty of reasons a clever (or even not so clever) Windows
developer can use to justify using MySQL or another open source DB
instead of PostgreSQL. It is a bit harder for the neophyte to find and
believe the compelling reasons to use PostgreSQL. We need to make it
easier to choose PostgreSQL not harder.

Think about it from this perspective. How many of you would even think
about working on a project if it required that you stop using your
favorite toolset, gmake? EMACS? grep? shell scripts? etc.?

Professional developers spend years honing their skills. Learning the
proper use of the tools involved is a very big part of the process.

IMHO, having a native port without native (read Visual C++) project
support is a a huge missed opportunity.

Further, lack of Windows project files implies that PostgreSQL just a
Unix port and that the Windows support is immature, whether the code is
well supported or not.

POSSIBLE SOLUTIONS:

The Visual C++ Workspaces and Projects files are actually text files
that have a defined format. I don't think the format is published but it
looks pretty easy to figure out.

The Visual C++ environment does not require dependency specification, it
builds dependency trees by keeping track of the #include files used
during preprocessing.

Because of this, it should be possible to:

A) Write a script/tool that reads the input files from Unix makefiles to
build a list of the files in PostgreSQL and place them in appropriate
projects.

or alternately:

B) A script/tool that recurses the directories and does the same sort of
thing. There could be some sort of mapping between directories and
projects in Visual C++.

In short, for most organizations being able to easily build using the
source is a prerequisite for USING an open source database, not just for
being part of the DEVELOPMENT effort.

-Curtis

P.S. I speak from personal experience, I would have been able to help
out a lot more if I didn't have to spend 90% of my time working with
PostgreSQL learning Unix (or relearning) and gnu tool issues. I don't
personally mind so much because I wanted to learn it better anyway, but
it has definitely limited my ability to help, so far. This is especially
true since I don't have the opportunity to immerse myself in
Unix/PostgreSQL for days at a time and suffer from significant switching
costs.

On Wednesday 22 January 2003 02:01, Dann Corbit wrote:

Maybe because most of the machines in the world (by a titanic landslide)
are Windoze boxes.

On the desktop, yes. On the server, no. PostgreSQL is nore intended for a
server, no? I can see the utility in having a development installation on a
Win32 box, though.

people to do it. Usually Open Source guys run *NIX

Taken a poll lately?

If Microsoft has its way there won't be any Open Source on Windows. Well,
PostgreSQL might squeak by due to the BSD license, but other licenses aren't
so fortunate, and GPL is anathema to Microsoft.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Wed, 2003-01-22 at 15:34, Curtis Faith wrote:

tom lane writes:

You think we should drive away our existing unix developers
in the mere hope of attracting windows developers? Sorry, it
isn't going to happen.

Tom brings up a good point, that changes to support Windows should not
add to the tasks of those who are doing the bulk of the work on Unixen.

I don't think, however, that this necessarily means that having Windows
developers use Cygwin is the right solution. We need to come up with a
way to support Windows Visual C++ projects without adding work to the
other developers.

Does anyone know how MySQL and interbase/firebird do it ?

POSSIBLE SOLUTIONS:

The Visual C++ Workspaces and Projects files are actually text files
that have a defined format. I don't think the format is published but it
looks pretty easy to figure out.

will probably change between releases (also I dont think you can easily
compile C source on a C# compiler) ;/

--
Hannu Krosing <hannu@tm.ee>

I (Curtis Faith) previously wrote:

The Visual C++ Workspaces and Projects files are actually
text files that have a defined format. I don't think the format is
published but it looks pretty easy to figure out.

Hannu Krosing replied:

will probably change between releases

Even if the format changes, the environment always has a converter that
updates the project and workspace files to the new format. In other
words, Visual C++ 6.0 reads 5.0 projects, 7.0 reads 6.0, etc.

The format is mostly a bunch of options specifications (which wouldn't
get touched) followed by a set of named groups of source files. Even if
the overall format changes, it will be much more likely to change in the
specifications rather than the way lists of source file formats are
specified.

A conversion tool, call it BuildWindowsProjectFile, would only need to:

1) Read in the template file (containing all the options specifications
and Visual C++ speficic stuff, debug and release target options,
libraries to link in, etc.) This part might change with new versions of
the IDE and would be manually created by someone with Visual C++
experience.

2) Read in the postgreSQL group/directory map, or alternately just
mirror the groups with the directories.

3) Output the files from the PostgreSQL directories in the appropriate
grouping according to the project format into the appropriate space in
the template.

An excerpt of the format follows:

# Begin Group "Access"
# Begin Group "Common"
# PROP Default_Filter "cpp;c;cxx"
# Begin Source File

SOURCE=.\access\common\heaptuple.c
# End Source File
# Begin Source File

SOURCE=.access\common\indextuple.c
# End Source File

... other files in access\common go here
# End Group

# Begin Group "Index"

# PROP Default_Filter "cpp;c;cxx"
# Begin Source File

SOURCE=.\access\index\genam.c
# End Source File
# Begin Source File

SOURCE=.access\index\indexam.c
# End Source File

... other files in access\index go here
# End Group

# End Group

As you can see, this is a really simple format, and the direct
folder/group mapping to PostgreSQL directory is pretty natural and
probably the way to go.

Using the approach I outline, it should be possible to have the Unix
make system automatically run the BuildWindowsProjectFile tool whenever
any makefile changes so the Windows projects would stay up to date
without additional work for Unix developers.

Hannu Krosing also wrote:

(also I dont think you can easily compile C source on a
C# compiler) ;/

I don't think it makes much sense target a compiler that won't compile
the source, therefore, if what you say is true, we shouldn't bother with
targeting C#.

- Curtis

This is a multi-part message in MIME format.

Hannu Krosing asked:

Does anyone know how MySQL and interbase/firebird do it ?

From the MySQL web site for version 4.0:

"The Windows binaries use the Cygwin library. Source code for the
version of Cygwin we have used is available on this page."

I think this offers a very big opportunity to differentiate. If we had
project support it would make PostgreSQL a more natural choice for
Windows developers.

Even in a shop that uses Unix servers with Windows front-ends, having a
database server that runs on your own machine makes it much easier to
debug, write code on airplanes, etc.

- Curtis

Jan Wieck writes:

We focused on porting the programs. The goal was to have PostgreSQL
running native on Win32 for a user. Having a nice and easy maintainable
cross platform config, build and test environment for the developers is
definitely something that still needs to be done (hint, hint).

I have prepared a little patch that makes room for a native Windows build
in our existing build framework. The Cygwin port would be renamed to
"cygwin" and the new port takes over the "win" name. I have prepared the
port specific template and makefile and extracted the dynaloader from your
patch, so that you can at least run configure under Cygwin or MinGW
successfully.

Then I suggest we merge in the obvious parts of your patch, especially the
renaming of various token constants, the shmem implementation, some
library function reimplementations. In some cases I would like a bit more
abstraction so that we don't have so many #ifdef's. (For example, we
could have a IsAbsolutePath() that works magically for all platforms.)

Then there are the hairy pieces. You add a bunch of command-line options
that interact in puzzling way to communicate information about the fake
fork. I think some of these are redundant, but it's hard to tell.

The reimplementation of various shell scripts in C is something that would
be a good idea on Unix as well for a number of reasons. Unfortunately,
the ones you wrote have no chance of compiling under Unix, so we'll have
to do it again. But that can happen in parallel to the other stuff.

Two quick questions: Why PG_WIN32 and not just WIN32? Can the ConsoleApp
thing be written in C so we don't have to get an extra C++ compiler for
one file (for those who don't want to use the Microsoft toolchain)?

--
Peter Eisentraut peter_e@gmx.net

Firebird uses a set of Borland command line tools and Borland's make,
which they give away as a free download. Even if you're compiling for
Windows, the build process uses Borland's command line "make". A batch
build script copies makefiles from a single source directory and spreads
them around the tree, then kicks off Borland's make. For things to work
successfully, you must download Borland's tools and install them
together with setting a few environment variables by hand. Borland
command line tools are just a set of Unix utilities like grep, sed,
make, (sh?) etc. Once upon a time they required cygwin utilities, but
managed to purge themselves of cygwin with the Borland utilities. When
they required cygwin, they also required some Borland utilities anyway.
So they had a real reason for purging cygwin. If someone thinks the
cygwin package is too big, we could require the Borland utilities instead :)

For my 2 cents, I would say the project files should be a separate
download. Let someone build, test, and contribute them for particular
versions of PostgreSQL. I would only try to make the Visual Studio
files work on true releases. I would _not_ try to keep them updated in
CVS or build them on the fly. W3.org's libwww does it something like this.

bbaker

On Wed, Jan 22, 2003 at 02:55:34PM -0400, Curtis Faith wrote:

Hannu Krosing also wrote:

(also I dont think you can easily compile C source on a
C# compiler) ;/

I don't think it makes much sense target a compiler that won't compile
the source, therefore, if what you say is true, we shouldn't bother with
targeting C#.

I don't think that compiling on a C# compiler is possible at all.
C# is too different from C. In fact, the C# language is much more similar
to Java than C/C++ ( there are no pointers, for example ).

--
Adrian Maier
(am@fx.ro, 40 723.002.097)

On Wednesday 22 January 2003 20:47, bbaker@priefert.com wrote:

Firebird uses a set of Borland command line tools and Borland's make,
which they give away as a free download. Even if you're compiling for
Windows, the build process uses Borland's command line "make". A batch
build script copies makefiles from a single source directory and spreads
them around the tree, then kicks off Borland's make. For things to work
successfully, you must download Borland's tools and install them
together with setting a few environment variables by hand. Borland
command line tools are just a set of Unix utilities like grep, sed,
make, (sh?) etc. Once upon a time they required cygwin utilities, but
managed to purge themselves of cygwin with the Borland utilities. When
they required cygwin, they also required some Borland utilities anyway.
So they had a real reason for purging cygwin. If someone thinks the
cygwin package is too big, we could require the Borland utilities instead
:)

I can't agree more ! Even if You do not want to hear my opinion here it is:

The reason why I started to use PosgreSQL was:
1. Price
2. Most features that I used on MSSQL was there (except replication).

If You require MS Visual C for building, it may increase the price.
Borland C++ free version 5.5 you can download from :
http://www.borland.com/products/downloads/download_cbuilder.html
(I newer downloaded it from there, because I got it on some CD from our
local computer news).
What is included in the package you can see at :
http://community.borland.com/article/0,1410,21205,00.html

I can point to one more example of using bcc32 in multiplatform projects:
http://www.trolltech.com/products/qt/windows.html
(They support also Microsoft Visual C++, but Windows version is not free !)

And in the end, the developers for windows are not stupid, they can survive
without MS projects, workspaces, fancy GUI e.t.c. (at least developers that
You want to contribute to Postgres.)

Curtis Faith wrote:

tom lane writes:

You think we should drive away our existing unix developers
in the mere hope of attracting windows developers? Sorry, it
isn't going to happen.

Tom brings up a good point, that changes to support Windows should not
add to the tasks of those who are doing the bulk of the work on Unixen.

I don't think, however, that this necessarily means that having Windows
developers use Cygwin is the right solution. We need to come up with a
way to support Windows Visual C++ projects without adding work to the
other developers.

[...]

IMHO, having a native port without native (read Visual C++) project
support is a a huge missed opportunity.

Perhaps. On the other hand, it may be much more work than it's worth.
See below.

The Visual C++ environment does not require dependency specification, it
builds dependency trees by keeping track of the #include files used
during preprocessing.

Because of this, it should be possible to:

A) Write a script/tool that reads the input files from Unix makefiles to
build a list of the files in PostgreSQL and place them in appropriate
projects.

or alternately:

B) A script/tool that recurses the directories and does the same sort of
thing. There could be some sort of mapping between directories and
projects in Visual C++.

This may be necessary, but I seriously doubt it's anywhere close to
sufficient. Right now, the Unix build relies on GNU autoconf to
generate the Makefiles and many other files (even include files). And
it doesn't just look for system-specific features and whatnot: it's
the means by which features are selected at build time (such as SSL
support, Kerberos support, which langauges to build runtime support
for, etc.). To use it requires a Unix shell and a bunch of command
line tools (e.g., sed). That's why Cygwin is required right now.

Somehow *all* of that has to either be replaced, or someone has to
decide which features will be built by all developers, or someone has
to do all the legwork of making the Windows source tree roughly as
configurable as the Unix one is. Doesn't sound like a terribly small
task to me, though it might not be too bad for someone who has a lot
of experience on both platforms. Since I don't have any real
experience doing development under Windows, I'm not one to really say.
But I thought you should at least know what you're up against.

I do agree that being able to build and debug PostgreSQL using
whichever tools are most commonly used amongst Windows developers
would be desirable, perhaps very much so...

--
Kevin Brown kevin@sysexperts.com

Curtis Faith wrote:

Hannu Krosing asked:
Does anyone know how MySQL and interbase/firebird do it ?

From the MySQL web site for version 4.0:

"The Windows binaries use the Cygwin library. Source code for the
version of Cygwin we have used is available on this page."

I think this offers a very big opportunity to differentiate. If we had
project support it would make PostgreSQL a more natural choice for
Windows developers.

MySQL uses Cygwin for libreadline support in the client 'mysqlc'. That's
pretty much it.

The rest is a standard Visual C++ project that has the files moved from
the unix sources via a script.

-Mark

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

I don't see a strong reason not
to stick with good old configure; make; make install. You're already
requiring various Unix-like tools, so you might as well require the full
shell environment.

Indeed. I think the goal here is to have a port that *runs* in native
Windows; but I see no reason not to require Cygwin for *building* it.

Agreed. I don't mind Cygwin if we don't have licensing problems with
distributing a Win32 binary that used Cygwin to build. I do have a
problem with MKS toolkit, which is a commerical purchase. I would like
to avoid reliance on that, though Jan said he needed their bash.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian kirjutas P, 26.01.2003 kell 05:07:

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

I don't see a strong reason not
to stick with good old configure; make; make install. You're already
requiring various Unix-like tools, so you might as well require the full
shell environment.

Indeed. I think the goal here is to have a port that *runs* in native
Windows; but I see no reason not to require Cygwin for *building* it.

Agreed. I don't mind Cygwin if we don't have licensing problems with
distributing a Win32 binary that used Cygwin to build. I do have a
problem with MKS toolkit, which is a commerical purchase. I would like
to avoid reliance on that, though Jan said he needed their bash.

IIRC mingw tools had win-native (cygwin-less) bash at

http://sourceforge.net/projects/mingw/

--
Hannu Krosing <hannu@tm.ee>

Hannu Krosing wrote:

Bruce Momjian kirjutas P, 26.01.2003 kell 05:07:

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

I don't see a strong reason not
to stick with good old configure; make; make install. You're already
requiring various Unix-like tools, so you might as well require the full
shell environment.

Indeed. I think the goal here is to have a port that *runs* in native
Windows; but I see no reason not to require Cygwin for *building* it.

Agreed. I don't mind Cygwin if we don't have licensing problems with
distributing a Win32 binary that used Cygwin to build. I do have a
problem with MKS toolkit, which is a commerical purchase. I would like
to avoid reliance on that, though Jan said he needed their bash.

IIRC mingw tools had win-native (cygwin-less) bash at

http://sourceforge.net/projects/mingw/

Have been watching this ongoing conversation and am in two frames of
mind about:

+ There are a lot of people on Win32 that are using MS Visual C or
Visual Studio

+ There are a few fairly well established Win32 programming IDE's that
are compatible with cygwin/mingw32

The advantages to having the Win32 port be natively compatible with
Visual Studio is that it already is (no toolset-porting work needed
there), but the disadvantage is that not just any Win32
user-with-an-interest can download it any try it out. So... that kind
of excludes it somewhat (Universities/colleges might have a problem too).

The advantages of having the Win32 port be natively compatible with
gcc/cygwin/something is that once it's converted to that toolchain, it
might be a lot less maintenance on us, as that's the toolset we use for
the Unix builds.

As a thought, the open source Dev-C++ IDE (Win32 and Linux) works with
gcc/cygwin/mingw32 and is pretty popular. Just checked it's homepage on
SourceForge (http://sourceforge.net/projects/dev-cpp/) and it's download
figures are pretty large. Since March 2002 (less than 1 year ago), it's
been downloaded about 120,000,000 times. Wow. 120 Million downloads in
less than 1 year. That's a pretty popular IDE (16th most popular
project on SourceForge)

Anyway, as a thought, my vote would be to make the Win32 port work in
with our toolchain or very similar (cygwin/mingw32/etc) if possible, so
we don't have to rely on people having Visual C. In developing
countries too, it's going to be much easier for people to get a hold of
things like Dev-C++ into the future as well.

Hope this provides a useful set of thoughts.

:-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Justin Clift wrote:
<snip>

Since March 2002 (less than 1 year ago), it's
been downloaded about 120,000,000 times. Wow. 120 Million downloads in
less than 1 year. That's a pretty popular IDE (16th most popular
project on SourceForge)

Arrrgh. Thought that sounded a bit too high.

Wrong column, it's actually only about 2 million times, not 120 million.

Should probably get more sleep. ;-)

Sorry about that guys.

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Are there no already-written converters from Makefile to VC project
files?

---------------------------------------------------------------------------

Curtis Faith wrote:

I (Curtis Faith) previously wrote:

The Visual C++ Workspaces and Projects files are actually
text files that have a defined format. I don't think the format is
published but it looks pretty easy to figure out.

Hannu Krosing replied:

will probably change between releases

Even if the format changes, the environment always has a converter that
updates the project and workspace files to the new format. In other
words, Visual C++ 6.0 reads 5.0 projects, 7.0 reads 6.0, etc.

The format is mostly a bunch of options specifications (which wouldn't
get touched) followed by a set of named groups of source files. Even if
the overall format changes, it will be much more likely to change in the
specifications rather than the way lists of source file formats are
specified.

A conversion tool, call it BuildWindowsProjectFile, would only need to:

1) Read in the template file (containing all the options specifications
and Visual C++ speficic stuff, debug and release target options,
libraries to link in, etc.) This part might change with new versions of
the IDE and would be manually created by someone with Visual C++
experience.

2) Read in the postgreSQL group/directory map, or alternately just
mirror the groups with the directories.

3) Output the files from the PostgreSQL directories in the appropriate
grouping according to the project format into the appropriate space in
the template.

An excerpt of the format follows:

# Begin Group "Access"
# Begin Group "Common"
# PROP Default_Filter "cpp;c;cxx"
# Begin Source File

SOURCE=.\access\common\heaptuple.c
# End Source File
# Begin Source File

SOURCE=.access\common\indextuple.c
# End Source File

... other files in access\common go here
# End Group

# Begin Group "Index"

# PROP Default_Filter "cpp;c;cxx"
# Begin Source File

SOURCE=.\access\index\genam.c
# End Source File
# Begin Source File

SOURCE=.access\index\indexam.c
# End Source File

... other files in access\index go here
# End Group

# End Group

As you can see, this is a really simple format, and the direct
folder/group mapping to PostgreSQL directory is pretty natural and
probably the way to go.

Using the approach I outline, it should be possible to have the Unix
make system automatically run the BuildWindowsProjectFile tool whenever
any makefile changes so the Windows projects would stay up to date
without additional work for Unix developers.

Hannu Krosing also wrote:

(also I dont think you can easily compile C source on a
C# compiler) ;/

I don't think it makes much sense target a compiler that won't compile
the source, therefore, if what you say is true, we shouldn't bother with
targeting C#.

- Curtis

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Theres a script at http://ptolemy.eecs.berkeley.edu/other/makevcgen which
may work, I've not tried it, but someone may want to give it a spin.

Combining it with the software at http://unxutils.sourceforge.net could give
us a MS build environment which only relies on installation support programs
rather than relying on the installation and use of the whole Cygwin
environment for the build process.

Al.

----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: "Curtis Faith" <curtis@galtair.com>
Cc: <pgsql-hackers@postgresql.org>
Sent: Monday, January 27, 2003 12:57 AM
Subject: [mail] Re: [HACKERS] Windows Build System

Are there no already-written converters from Makefile to VC project
files?

--------------------------------------------------------------------------

-

Curtis Faith wrote:

I (Curtis Faith) previously wrote:

The Visual C++ Workspaces and Projects files are actually
text files that have a defined format. I don't think the format is
published but it looks pretty easy to figure out.

Hannu Krosing replied:

will probably change between releases

Even if the format changes, the environment always has a converter that
updates the project and workspace files to the new format. In other
words, Visual C++ 6.0 reads 5.0 projects, 7.0 reads 6.0, etc.

The format is mostly a bunch of options specifications (which wouldn't
get touched) followed by a set of named groups of source files. Even if
the overall format changes, it will be much more likely to change in the
specifications rather than the way lists of source file formats are
specified.

A conversion tool, call it BuildWindowsProjectFile, would only need to:

1) Read in the template file (containing all the options specifications
and Visual C++ speficic stuff, debug and release target options,
libraries to link in, etc.) This part might change with new versions of
the IDE and would be manually created by someone with Visual C++
experience.

2) Read in the postgreSQL group/directory map, or alternately just
mirror the groups with the directories.

3) Output the files from the PostgreSQL directories in the appropriate
grouping according to the project format into the appropriate space in
the template.

An excerpt of the format follows:

# Begin Group "Access"
# Begin Group "Common"
# PROP Default_Filter "cpp;c;cxx"
# Begin Source File

SOURCE=.\access\common\heaptuple.c
# End Source File
# Begin Source File

SOURCE=.access\common\indextuple.c
# End Source File

... other files in access\common go here
# End Group

# Begin Group "Index"

# PROP Default_Filter "cpp;c;cxx"
# Begin Source File

SOURCE=.\access\index\genam.c
# End Source File
# Begin Source File

SOURCE=.access\index\indexam.c
# End Source File

... other files in access\index go here
# End Group

# End Group

As you can see, this is a really simple format, and the direct
folder/group mapping to PostgreSQL directory is pretty natural and
probably the way to go.

Using the approach I outline, it should be possible to have the Unix
make system automatically run the BuildWindowsProjectFile tool whenever
any makefile changes so the Windows projects would stay up to date
without additional work for Unix developers.

Hannu Krosing also wrote:

(also I dont think you can easily compile C source on a
C# compiler) ;/

I don't think it makes much sense target a compiler that won't compile
the source, therefore, if what you say is true, we shouldn't bother with
targeting C#.

- Curtis

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

--
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 359-1001
+  If your life is a hard drive,     |  13 Roberts Road
+  Christ can be your backup.        |  Newtown Square, Pennsylvania

19073

----- Original Message -----

Bruce Momjian replied

Are there no already-written converters from Makefile to VC project
files?

The only ones I've seen convert from Unix make files to Windows NMAKE
make files. This does not really do everything you want for several
reasons:

1) Building with make files doesn’t take advantage of the IDE for code
organization, navigation and is not the kind of support that would be
included for a "well supported" Windows product.

2) There is no automatic way to convert compiler options from gcc to
Visual C

3) There is no way to convert the concept of different build targets
(debug, release, etc.) in the way that the IDE looks at it. This is
analogous but different from the way a make file handles different
targets.

4) There was some discussion on the list that some features of Visual
C++ were required for the port itself, something about directory
replacement for include files. It is likely that this requires a special
setup for the Visual C++ project which would not be easy to handle with
just a NMAKE combatible make file.

Al Sutton replied:

Theres a script at
http://ptolemy.eecs.berkeley.edu/other/makevcgen which may
work, I've not tried it, but someone may want to give it a spin.

The script he describes here is one of the make file converters I
describe above.

I volunteer to write a tool in generic C to do the conversion if the
approach I outlined is deemed a good solution by those that decide such
things.

The real question is what is the motivator for a native Windows port. If
the answer is to remove CygWin dependency, that begs the further
question of why is removing CygWin dependency a good idea?

One of the reasons has to be that any obstacles that stand in the way of
getting an implementation compiled and installed will make it less
likely that developers will use it.I believe that a native Windows
version that had strong Visual C++ support will win many converts from
MySQL because it will make it much easier for someone who is looking for
an open source database to try compiling PostgreSQL. Most people looking
at open source solutions will want to at least poke around in the source
and build from that source.

If a developer can simply download the source, click on the Visual C++
project in the win32 directory and then build PostgreSQL, and they can
see that Windows is not the "poor stepchild" because the VC project is
well laid out, they will be more likely to use it for Windows projects
than MySQL which requires the CygWin tools (this means "really a Unix
product" to Windows developers).

- Curtis

Bruce Momjian writes:

I do have a problem with MKS toolkit, which is a commerical purchase.
I would like to avoid reliance on that, though Jan said he needed their
bash.

I don't believe that quite yet. Jan said the regression test script
crashes Cygwin's bash, but how come it has never crashed anyone else's
Cygwin bash?

--
Peter Eisentraut peter_e@gmx.net

Justin Clift writes:

The advantages to having the Win32 port be natively compatible with
Visual Studio is that it already is (no toolset-porting work needed
there),

You're missing a couple of points here. First, the MS Visual whatever
compiler can also be used with a makefile-driven build system. Second,
the port as it stands isn't really compatible with anything except Jan's
build instructions. There's a lot of work to be done before we get
anything that builds out of the box in the 7.4 branch, and it's going to
be a lot easier if we do it using the build system we already have and
know.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut wrote:

Justin Clift writes:

The advantages to having the Win32 port be natively compatible with
Visual Studio is that it already is (no toolset-porting work needed
there),

You're missing a couple of points here. First, the MS Visual whatever
compiler can also be used with a makefile-driven build system. Second,
the port as it stands isn't really compatible with anything except Jan's
build instructions. There's a lot of work to be done before we get
anything that builds out of the box in the 7.4 branch, and it's going to
be a lot easier if we do it using the build system we already have and
know.

Thanks Peter. Really didn't know that MS Visual <things> could work
with makefile driven build systems, nor that the PeerDirect build
process was so... unique. :)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

On Wednesday 22 January 2003 11:49, Hannu Krosing wrote:

On Wed, 2003-01-22 at 15:34, Curtis Faith wrote:

tom lane writes:

You think we should drive away our existing unix developers
in the mere hope of attracting windows developers? Sorry, it
isn't going to happen.

Tom brings up a good point, that changes to support Windows should not
add to the tasks of those who are doing the bulk of the work on Unixen.

I don't think, however, that this necessarily means that having Windows
developers use Cygwin is the right solution. We need to come up with a
way to support Windows Visual C++ projects without adding work to the
other developers.

Does anyone know how MySQL and interbase/firebird do it ?

Xerces and Xalan from Apache both include VC6 projects. The projects are
kept in their own directory apart from source code. You might want to
download the Xerces and Xalan source and look at how they structured
their envrionment.

I *does* make it easier for Windows developers to work with VC6 projects.

Alan Gutierrez - ajglist@izzy.net
http://khtml-win32.sourceforge.net/ - KHTML on Windows

"Curtis Faith" <curtis@galtcapital.com> writes:

If a developer can simply download the source, click on the Visual C++
project in the win32 directory and then build PostgreSQL, and they can
see that Windows is not the "poor stepchild" because the VC project is
well laid out, they will be more likely to use it for Windows projects
than MySQL which requires the CygWin tools (this means "really a Unix
product" to Windows developers).

<flame on>
In all honesty, I do not *want* Windows people to think that they're not
running on the "poor stepchild" platform. If we go down that path,
they'll start trying to run production databases on Windows, and then
we'll get blamed for the instability of the platform, not to mention
the likelihood that it ignores Unix semantics for fsync() and suchlike
critical primitives.

I have no objection to there being a Windows port that people can use
to do SQL-client development on their laptops. But let us please not
confuse this with an industrial-strength solution; nor give any level
of support that might lead others to make such confusion.

The MySQL guys made the right choice here: they don't want to buy into
making Windows a grade-A platform, either.
<flame off>

regards, tom lane

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Tom Lane
Sent: Wednesday, January 29, 2003 3:37 AM
To: Curtis Faith
Cc: 'Al Sutton'; 'Bruce Momjian'; pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

"Curtis Faith" <curtis@galtcapital.com> writes:

If a developer can simply download the source, click on the Visual C++
project in the win32 directory and then build PostgreSQL, and they can
see that Windows is not the "poor stepchild" because the VC project is
well laid out, they will be more likely to use it for Windows projects
than MySQL which requires the CygWin tools (this means "really a Unix
product" to Windows developers).

<flame on>
In all honesty, I do not *want* Windows people to think that they're not
running on the "poor stepchild" platform. If we go down that path,
they'll start trying to run production databases on Windows, and then
we'll get blamed for the instability of the platform, not to mention
the likelihood that it ignores Unix semantics for fsync() and suchlike
critical primitives.

I have no objection to there being a Windows port that people can use
to do SQL-client development on their laptops. But let us please not
confuse this with an industrial-strength solution; nor give any level
of support that might lead others to make such confusion.

The MySQL guys made the right choice here: they don't want to buy into
making Windows a grade-A platform, either.
<flame off>

regards, tom lane

Wow. I've been listening to the pros and cons for a while, and they've been
really interesting. However, to assume without ever using the native
Windows port that it is automatically a "poor stepchild" is unbelievable.

I believe that the port, as submitted, can be used as an industrial-strength
solution. I challenge you all to prove me wrong, but until you do, please
lay off the assumptions.

Regards,
Katie Ward
Principle Developer
PeerDirect Corporation

On Wed, 29 Jan 2003, Katie Ward wrote:

<flame on>
In all honesty, I do not *want* Windows people to think that they're not
running on the "poor stepchild" platform. If we go down that path,
they'll start trying to run production databases on Windows, and then
we'll get blamed for the instability of the platform, not to mention
the likelihood that it ignores Unix semantics for fsync() and suchlike
critical primitives.

I have no objection to there being a Windows port that people can use
to do SQL-client development on their laptops. But let us please not
confuse this with an industrial-strength solution; nor give any level
of support that might lead others to make such confusion.

The MySQL guys made the right choice here: they don't want to buy into
making Windows a grade-A platform, either.
<flame off>

regards, tom lane

Wow. I've been listening to the pros and cons for a while, and they've been
really interesting. However, to assume without ever using the native
Windows port that it is automatically a "poor stepchild" is unbelievable.

I believe that the port, as submitted, can be used as an industrial-strength
solution. I challenge you all to prove me wrong, but until you do, please
lay off the assumptions.

The only assumption I see being made here is this:

"I believe that the port, as submitted, can be used as an
industrial-strength solution."

I see no evidence to support this claim. If you have this evidence,
feel free to share it with the rest of us.

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: 29 January 2003 16:27
To: Katie Ward
Cc: Tom Lane; Curtis Faith; pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

The only assumption I see being made here is this:

"I believe that the port, as submitted, can be used as an
industrial-strength solution."

I see no evidence to support this claim. If you have this
evidence, feel free to share it with the rest of us.

I hammered the betas on a couple of test boxes running Windows XP and
.NET Server of various (pre)releases and found it to be rock solid,
performing comparably to my Linux based systems. The Cygwin version fell
over quite quickly under the same tests.

I'll admit my methods were not particularly scientific, but over the
last few weeks I've had far more grief from DB2 and SQL Server than I
did from the PostgreSQL native betas.

Regards, Dave.

On Wed, 29 Jan 2003, Dave Page wrote:

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: 29 January 2003 16:27
To: Katie Ward
Cc: Tom Lane; Curtis Faith; pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

The only assumption I see being made here is this:

"I believe that the port, as submitted, can be used as an
industrial-strength solution."

I see no evidence to support this claim. If you have this
evidence, feel free to share it with the rest of us.

I hammered the betas on a couple of test boxes running Windows XP and
.NET Server of various (pre)releases and found it to be rock solid,
performing comparably to my Linux based systems. The Cygwin version fell
over quite quickly under the same tests.

I'll admit my methods were not particularly scientific, but over the
last few weeks I've had far more grief from DB2 and SQL Server than I
did from the PostgreSQL native betas.

hammering the betas is a far cry from an "industrial-strength solution".

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: 29 January 2003 16:36
To: Dave Page
Cc: Katie Ward; Tom Lane; Curtis Faith; pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

On Wed, 29 Jan 2003, Dave Page wrote:

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: 29 January 2003 16:27
To: Katie Ward
Cc: Tom Lane; Curtis Faith; pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

The only assumption I see being made here is this:

"I believe that the port, as submitted, can be used as an
industrial-strength solution."

I see no evidence to support this claim. If you have

this evidence,

feel free to share it with the rest of us.

I hammered the betas on a couple of test boxes running

Windows XP and

.NET Server of various (pre)releases and found it to be rock solid,
performing comparably to my Linux based systems. The Cygwin version
fell over quite quickly under the same tests.

I'll admit my methods were not particularly scientific, but

over the

last few weeks I've had far more grief from DB2 and SQL

Server than I

did from the PostgreSQL native betas.

hammering the betas is a far cry from an "industrial-strength
solution".

Have you a better suggestion? Seems a bit catch 22 if testing won't
prove it's good and we can't use it until we know it's good... Still,
industrial strength testing or not, it's more reliable than the SQL 2000
and DB2 installations I have here.

Regards, Dave.

On Wed, 29 Jan 2003, Dave Page wrote:

hammering the betas is a far cry from an "industrial-strength
solution".

Have you a better suggestion? Seems a bit catch 22 if testing won't
prove it's good and we can't use it until we know it's good... Still,
industrial strength testing or not, it's more reliable than the SQL 2000
and DB2 installations I have here.

Well you have a beta running, load it up with data and let a few hundred
clients loose on it. I've seen win2k BSOD with less stress than that.

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

tom lane wrote:

<flame on>
In all honesty, I do not *want* Windows people to think that
they're not running on the "poor stepchild" platform.

We should distinguish between "poor stepchild" from a client support
perspective and a production environment perspective.

What is the downside to supporting development of client products
better? That is what I am really suggesting.

If people are deciding what open-source database server they want to
use, Linux or FreeBSD is the obvious choice for the server OS. The kind
of people who are inclined to use PostgreSQL or MySQL will mostly NOT be
considering Windows servers.

I have no objection to there being a Windows port that people
can use to do SQL-client development on their laptops. But
let us please not confuse this with an industrial-strength
solution; nor give any level of support that might lead
others to make such confusion.

All we can do is simply to make it clear that Windows
is not recommended for production server use and outline
all the reasons why Windows sucks for that purpose.

Beyond that, if people want to shoot themselves in the head, they will
do so and I don't see much point in trying to stop them.

The MySQL guys made the right choice here: they don't want to
buy into making Windows a grade-A platform, either. <flame off>

<flame retardent on>
How does providing a native Windows executable that doesn't require
Cygwin accomplish your objective. It seems to me that you are going to
have the problem if you release a native version irrespective of the
issue at hand (Visual C++ project support).

I don't see how making it easier to build adds to this problem.

I also don't see how making it harder for Windows client developer to
adopt PostgreSQL helps anyone. <flame retardent off>

I hate Microsoft and I don't like Windows, but I am forced to use it
because the software we need to run our business runs only on
Windows. I use Unix whenever possible and whenever reliability is
required.

- Curtis

P.S. The lack of a real C++ client library that supports the most common
development environment out there is another problem that seriously
impedes Windows client developers.

I like libpqxx, Jeroen did a find job. However, one needs to
jump through hoops to get it to run on Visual C++ 6.0 at
the moment.

"Dave Page" <dpage@vale-housing.co.uk> writes:

I'll admit my methods were not particularly scientific, but over the
last few weeks I've had far more grief from DB2 and SQL Server than I
did from the PostgreSQL native betas.

My gripe had to do with questioning the reliability of the platform, not
of the Postgres port ;-).

Aside from load testing as suggested by Vince, I'd be interested to hear
what happens when you pull the power cord under load (repeatedly). This
would give some evidence about the robustness of the Windows filesystem
and its ability to emulate Unix sync semantics.

regards, tom lane

On Wed, 29 Jan 2003, Katie Ward wrote:

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Vince Vielhaber
Sent: Wednesday, January 29, 2003 11:45 AM
To: Dave Page
Cc: Katie Ward; Tom Lane; Curtis Faith; pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

On Wed, 29 Jan 2003, Dave Page wrote:

hammering the betas is a far cry from an "industrial-strength
solution".

Have you a better suggestion? Seems a bit catch 22 if testing won't
prove it's good and we can't use it until we know it's good... Still,
industrial strength testing or not, it's more reliable than the SQL 2000
and DB2 installations I have here.

Well you have a beta running, load it up with data and let a few hundred
clients loose on it. I've seen win2k BSOD with less stress than that.

Vince.

We did that as part of our internal testing, using the ATM database and a
dual-processor machine. We tried both with clients connecting and
disconnection quickly, and with large numbers of clients that stayed
connected for a while, all extremely active. Native Win32 performed
comparably with running the same test on comparable machines on LINUX.
Nothing crashed.

The code's been available for what a week or two? Do you actually
think that can be considered conclusive by any standard?

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: 29 January 2003 16:45
To: Dave Page
Cc: Katie Ward; Tom Lane; Curtis Faith; pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

On Wed, 29 Jan 2003, Dave Page wrote:

hammering the betas is a far cry from an "industrial-strength
solution".

Have you a better suggestion? Seems a bit catch 22 if testing won't
prove it's good and we can't use it until we know it's

good... Still,

industrial strength testing or not, it's more reliable than the SQL
2000 and DB2 installations I have here.

Well you have a beta running, load it up with data and let a
few hundred clients loose on it. I've seen win2k BSOD with
less stress than that.

That's what I was doing, loading it up with hundreds of connections from
other boxes, using osdb and pgbench. I'm not saying it's bug free, or
that Win2K won't crash under it, but it performed well for me - better
than 2 of the leading commercial databases.

I agree with Katie, dismissing a largely untested product because it
runs on Windows is not a good thing. Yes, Windows can BSOD, but when a
system is built on good hardware (for which good quality drivers are
available), and configured well it can be as reliable, if not more so
than some versions of Linux that have been released.

I would be interested to know how many windows servers those that are
against a windows port of PostgreSQL have or do manage, and how
experienced they are with that platform...

Regards, Dave.

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: 29 January 2003 16:57
To: Katie Ward
Cc: Dave Page; Tom Lane; Curtis Faith; pgsql-hackers@postgresql.org
Subject: RE: [mail] Re: [HACKERS] Windows Build System

The code's been available for what a week or two? Do you
actually think that can be considered conclusive by any standard?

Public beta testing (but closed source) has been going on for some
months.

Regards, Dave.

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 29 January 2003 16:57
To: Dave Page
Cc: Vince Vielhaber; Katie Ward; Curtis Faith;
pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

"Dave Page" <dpage@vale-housing.co.uk> writes:

I'll admit my methods were not particularly scientific, but

over the

last few weeks I've had far more grief from DB2 and SQL

Server than I

did from the PostgreSQL native betas.

My gripe had to do with questioning the reliability of the
platform, not of the Postgres port ;-).

Aside from load testing as suggested by Vince, I'd be
interested to hear what happens when you pull the power cord
under load (repeatedly). This would give some evidence about
the robustness of the Windows filesystem and its ability to
emulate Unix sync semantics.

OK, I can maybe do some testing on that next week (I'm off for a few
days from today). Is there anything in particular I should look out for,
or that you would want tested?

Katie, can I get the latest build from anywhere?

Regards, Dave.

On Wed, 29 Jan 2003, Dave Page wrote:

I would be interested to know how many windows servers those that are
against a windows port of PostgreSQL have or do manage, and how
experienced they are with that platform...

At this point I'm not for or against. But you're going to have to do
more than a weeks worth of unscientific testing to prove your point
and move from assumptions to facts.

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

"Dave Page" <dpage@vale-housing.co.uk> writes:

Aside from load testing as suggested by Vince, I'd be
interested to hear what happens when you pull the power cord
under load (repeatedly). This would give some evidence about
the robustness of the Windows filesystem and its ability to
emulate Unix sync semantics.

OK, I can maybe do some testing on that next week (I'm off for a few
days from today). Is there anything in particular I should look out for,
or that you would want tested?

Make sure your test load includes lots of updating queries, and look for
database corruption --- bad data, duplicated rows, lost rows, that sort
of thing.

regards, tom lane

On Wed, 29 Jan 2003, Dave Page wrote:

The code's been available for what a week or two? Do you
actually think that can be considered conclusive by any standard?

Public beta testing (but closed source) has been going on for some
months.

So you've been running these unscientific tests you're telling us
about being so successful for "some months"?

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: 29 January 2003 17:10
To: Dave Page
Cc: Katie Ward; Tom Lane; Curtis Faith; pgsql-hackers@postgresql.org
Subject: RE: [mail] Re: [HACKERS] Windows Build System

On Wed, 29 Jan 2003, Dave Page wrote:

I would be interested to know how many windows servers

those that are

against a windows port of PostgreSQL have or do manage, and how
experienced they are with that platform...

At this point I'm not for or against. But you're going to
have to do more than a weeks worth of unscientific testing to
prove your point and move from assumptions to facts.

No problem with that. Likewise however, it'd be nice if people weren't
against the windows port until testing had proved it didn't work
properly. Would we have the same general reactions to a revived VMS port
or one for OS/2 (not counting Tom's which is an valid concern over a
specific issue)? I suspect not...

Regards, Dave.

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: 29 January 2003 17:13
To: Dave Page
Cc: Katie Ward; Tom Lane; Curtis Faith; pgsql-hackers@postgresql.org
Subject: RE: [mail] Re: [HACKERS] Windows Build System

On Wed, 29 Jan 2003, Dave Page wrote:

The code's been available for what a week or two? Do you

actually

think that can be considered conclusive by any standard?

Public beta testing (but closed source) has been going on for some
months.

So you've been running these unscientific tests you're
telling us about being so successful for "some months"?

No, I've spent a few days here and there on it, and left things running
for the odd couple of days. I'm certainly not the only tester though.

Regards, Dave.

On Wed, 29 Jan 2003, Katie Ward wrote:

On Wed, 29 Jan 2003, Katie Ward wrote:

On Wed, 29 Jan 2003, Dave Page wrote:

hammering the betas is a far cry from an "industrial-strength
solution".

Have you a better suggestion? Seems a bit catch 22 if testing won't
prove it's good and we can't use it until we know it's

good... Still,

industrial strength testing or not, it's more reliable than

the SQL 2000

and DB2 installations I have here.

Well you have a beta running, load it up with data and let a

few hundred

clients loose on it. I've seen win2k BSOD with less stress than that.

Vince.

We did that as part of our internal testing, using the ATM

database and a

dual-processor machine. We tried both with clients connecting and
disconnection quickly, and with large numbers of clients that stayed
connected for a while, all extremely active. Native Win32 performed
comparably with running the same test on comparable machines on LINUX.
Nothing crashed.

The code's been available for what a week or two? Do you actually
think that can be considered conclusive by any standard?

Vince.

I am the lead developer on the native windows port. I have been using and
testing it for 6 months. However, what testing is ever conclusive?. It is
just evidence that more testing by more people should be done.

Testing to what standards? IMO the lead developer performing these tests
is even less than scientific. There are things you will always know that
someone else testing it won't know and they will be more likely to try
something that you wouldn't that may show less than stellar results.
You've tried what's supposed to work, but how much effort have you put in
that's not supposed to work? Are you that sure that if you were to feed
an oddball query that will simply close the backend on a unix platform
won't send your OS off into the weeds?

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

On Wed, 29 Jan 2003, Dave Page wrote:

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: 29 January 2003 17:10
To: Dave Page
Cc: Katie Ward; Tom Lane; Curtis Faith; pgsql-hackers@postgresql.org
Subject: RE: [mail] Re: [HACKERS] Windows Build System

On Wed, 29 Jan 2003, Dave Page wrote:

I would be interested to know how many windows servers

those that are

against a windows port of PostgreSQL have or do manage, and how
experienced they are with that platform...

At this point I'm not for or against. But you're going to
have to do more than a weeks worth of unscientific testing to
prove your point and move from assumptions to facts.

No problem with that. Likewise however, it'd be nice if people weren't
against the windows port until testing had proved it didn't work
properly. Would we have the same general reactions to a revived VMS port
or one for OS/2 (not counting Tom's which is an valid concern over a
specific issue)? I suspect not...

VMS and OS/2 have proven track records of being rugged. Windows has
always had a reputation of being fragile. And yes, I have extensive
experience with all three.

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

The latest build is still: ftp://209.61.187.152/postgres/postgres_beta4.zip

This is not exactly what Jan submitted, and the catalog number is slightly
different, but it should do for testing.

Katie

Curtis Faith wrote:
<snip>

If people are deciding what open-source database server they want to
use, Linux or FreeBSD is the obvious choice for the server OS. The kind
of people who are inclined to use PostgreSQL or MySQL will mostly NOT be
considering Windows servers.

For another perspective, we've been getting a few requests per day
through the PostgreSQL Advocacy and Marketing site's request form along
the lines of:

"Is there a license fee for using PostgreSQL? We'd like to distribute
it with our XYZ product that needs a database."

Probably about 4 or so per day like this at present. A lot of the
people sending these emails appear to have windows based products that
need a database, and have heard of PostgreSQL being a database that they
don't need to pay license fee's for. They've kind of missed the point
of Open Source from the purist point of view, but it's still working for
them. ;-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Vince Vielhaber wrote:

On Wed, 29 Jan 2003, Dave Page wrote:

The code's been available for what a week or two? Do you
actually think that can be considered conclusive by any standard?

Public beta testing (but closed source) has been going on for some
months.

So you've been running these unscientific tests you're telling us
about being so successful for "some months"?

Vince.

I open my mouth and insert foot: Where do I get any of these scientific
tests to determine if the latest and greatest 7.3.x will not fall down on my
favorite Unix?

James Hubbard

Katie Ward wrote:

The latest build is still: ftp://209.61.187.152/postgres/postgres_beta4.zip

This is not exactly what Jan submitted, and the catalog number is slightly
different, but it should do for testing.

In case anyone's interested, there are step by step installation
instructions for it at:

http://techdocs.postgresql.org/guides/InstallingOnWindows

;-)

Regards and best wishes,

Justin Clift

Katie

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

*sigh*

Often there isn't a choice of OS. If I am selling to a large enterprise
whose corporate standards say they will only run Windows in their data
center, my chances of getting them to make an exception are none. But my
chances of getting them to install Pg just for my application are far
greater. Would I prefer *nix? You betcha. Would I break a deal over it? No.
Would I prefer to be able to recommend Pg over, say, Oracle, or MS-SQL?
Absolutely. I'm not alone.

I don't care how it's built. I have a lot of sympathy for the folks saying
make the build process universal, rather than having a special one for
Windows. Requiring cygwin shouldn't be a big deal. You aren't going to get a
sudden flood of *nix-ignorant windows developers rushing in, no matter what
you do.

I've been mildly surprised and disappointed by the venom I detect in this
thread. I want to be able to recommend a single Db to my customers no matter
what OS they run. MySQL just doesn't do it, SAPdB is a nightmare, Pg is my
last hope other than a proprietary system. If you are an OpenSource zealot,
think of this as an opportunity to get some into places where it is often
anaethema.

cheers

andrew

----- Original Message -----
From: "Curtis Faith" <curtis@galtcapital.com>
To: <pgsql-hackers@postgresql.org>
Sent: Wednesday, January 29, 2003 11:54 AM
Subject: Re: [mail] Re: [HACKERS] Windows Build System

On Wed, 29 Jan 2003, James Hubbard wrote:

Vince Vielhaber wrote:

On Wed, 29 Jan 2003, Dave Page wrote:

The code's been available for what a week or two? Do you
actually think that can be considered conclusive by any standard?

Public beta testing (but closed source) has been going on for some
months.

So you've been running these unscientific tests you're telling us
about being so successful for "some months"?

Vince.

I open my mouth and insert foot: Where do I get any of these scientific
tests to determine if the latest and greatest 7.3.x will not fall down on my
favorite Unix?

If you're looking for a tool to test with, there was an announcement here
not too long ago for one. But it goes beyond just running a test suite
against it. Many of the available tools are designed to test what works
and how well it works. Testing goes beyond that. You want to know what
doesn't work, does the database return to a normal state if the unthinkable
happens (eg. Tom's suggestion of yanking the plug), how about loss of
network communications or sudden intermittant communication? Or the
function that may not be checking its input that well - when it fails is
everything ok or did that transaction someone else was in the middle of
get blown away?

A gal that used to do MSDOS testing for MS (Jen something, don't recall
her last name) would pull a floppy out in the middle of read or write
and found a certain sequence would either hose the floppy, get the system
to reboot (don't recall the exact details, it's been YEARS).

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

James Hubbard wrote:
<snip>

I open my mouth and insert foot: Where do I get any of these scientific
tests to determine if the latest and greatest 7.3.x will not fall down
on my favorite Unix?

For Open Source benchmarks, there is:

Open Source Database Benchmark:
http://osdb.sf.net

With this, you *want* to use the latest CVS version, as that can
generate it's own datasets of any size. The older, released versions
couldn't and you had to download databases of limited size.

Database Opensource Test Suite:
http://ltp.sourceforge.net/dotshowto.php

This works with DB2, Oracle, Sybase, MySQL, and PostgreSQL, and looks to
have been developed by IBM. Haven't yet used this, but did notice that
the configuration instructions make no reference to upping the memory
buffers. i.e. all of the tests they've done were probably with the
defaults (yuck!)

Emailed this group yesterday asking if they're open to suggestions for
improvement, and they said they definitely are. If anyone has specific
they'd like to let them know, they do seem open to it.

A commercial solution that people often mention is Benchmark Factory:

http://www.benchmarkfactory.com

Haven't personally used it, although it's apparently the software that
Great Bridge used for all of their testing.

Hope this helps.

Regards and best wishes,

Justin Clift

James Hubbard

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Vince Vielhaber wrote:

<snip>

So you've been running these unscientific tests you're telling us
about being so successful for "some months"?

Vince.

I open my mouth and insert foot: Where do I get any of these scientific
tests to determine if the latest and greatest 7.3.x will not fall down on my
favorite Unix?

If you're looking for a tool to test with, there was an announcement here
not too long ago for one. But it goes beyond just running a test suite
against it. Many of the available tools are designed to test what works
and how well it works. Testing goes beyond that. You want to know what
doesn't work, does the database return to a normal state if the unthinkable
happens (eg. Tom's suggestion of yanking the plug), how about loss of
network communications or sudden intermittant communication? Or the
function that may not be checking its input that well - when it fails is
everything ok or did that transaction someone else was in the middle of
get blown away?

A gal that used to do MSDOS testing for MS (Jen something, don't recall
her last name) would pull a floppy out in the middle of read or write
and found a certain sequence would either hose the floppy, get the system
to reboot (don't recall the exact details, it's been YEARS).

I'm not disagreeing with you on testing. I've seen the announcments.
Justin Clift just posted them again. But, as far as I've seen there are no
real scientific tests that anyone here has posted. I've seen the occasional
post with db_bench. You asked "To what standards?" I've not seen any
standards that are meaningful. Maybe I'm just not looking.

Any benchmarks/tests that someone posts are going to be subjective anyway.
No one seems to be using the same tool. The osdb is step in the right
direction, but I've not really seen anyone using it. The regressions are
the only thing that I can see and run. It would be nice if there were a few
people that had test setups that could post benchmarks/tests, so that we
could see how things look for each release.
(i.e.: on the 5GB test, it did this; when I cut the power and turned it
back onn it did this and this.)

When I download, install, and use postgresql, I take it on faith that it
will perform as the developers say that it does. Maybe this is a bad thing,
but I don't think so My use of it is very meager at the best so I don't
have a lot to worry about. If I had loads of data and mission critical apps
I would probably test a lot, but I don't.

All I'm saying is to cut them some slack and give them some ideas to test
until there is a really good testing/benchmarking tool that everyone can use
that won't be as subjective.

I personally want this to succeed. After having to use MySQL for a class
project, I don't really want to use it again. I had to use because it was
the only cross platform tool. Not everyone in the class was running linux or
xBSD, so I had to go with MySQL. From what I've seen, It looks like I'll
have to anyhow because that's what many job ads are looking for.

I believe Oracle used the excuse that PostgreSQL was unproven, when they
complained about its use for the .org registry. What we may think about
Windows being fragile and being a piece of crap doesn't really matter.
People are using it and it's at least doing they want.

I've probably not said this before, but I appreciate all the hard work that
everyone puts into this project.

James Hubbard

Peter Eisentraut wrote:

Justin Clift writes:

The advantages to having the Win32 port be natively compatible with
Visual Studio is that it already is (no toolset-porting work needed
there),

You're missing a couple of points here. First, the MS Visual whatever
compiler can also be used with a makefile-driven build system. Second,
the port as it stands isn't really compatible with anything except Jan's
build instructions. There's a lot of work to be done before we get
anything that builds out of the box in the 7.4 branch, and it's going to
be a lot easier if we do it using the build system we already have and
know.

Absolutely right, I know that the build environment is more a mess than
an environment. All I said is that we have a stable, working, native
Win32 PostgreSQL 7.2.1 ...

And I don't care if we use MingW, Borland, Cygwin or a big blend of it
all, as long as the final result can be shipped binary under the BSD
license.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

-----Original Message-----
From: Jan Wieck [mailto:JanWieck@Yahoo.com]
Sent: Wednesday, January 29, 2003 11:47 AM
To: Peter Eisentraut
Cc: Justin Clift; Hannu Krosing; Bruce Momjian; Tom Lane;
Postgres development
Subject: Re: [HACKERS] Win32 port patches submitted

Peter Eisentraut wrote:

Justin Clift writes:

The advantages to having the Win32 port be natively

compatible with

Visual Studio is that it already is (no toolset-porting

work needed

there),

You're missing a couple of points here. First, the MS

Visual whatever

compiler can also be used with a makefile-driven build system.
Second, the port as it stands isn't really compatible with anything
except Jan's build instructions. There's a lot of work to be done
before we get anything that builds out of the box in the

7.4 branch,

and it's going to be a lot easier if we do it using the

build system

we already have and know.

Absolutely right, I know that the build environment is more a
mess than an environment. All I said is that we have a
stable, working, native Win32 PostgreSQL 7.2.1 ...

And I don't care if we use MingW, Borland, Cygwin or a big
blend of it all, as long as the final result can be shipped
binary under the BSD license.

It would be very nice if we could drive the whole thing under Mingw. It
has an environment that the current developers will be familiar with
(bash, ksh, GCC, etc.) and probably some scripts could perform all the
manual operations.

Is there a place I can download the current patched tree? I might look
at automating the process to some degree.

Justin Clift wrote:

For another perspective, we've been getting a few requests per day
through the PostgreSQL Advocacy and Marketing site's request form along
the lines of:

"Is there a license fee for using PostgreSQL? We'd like to distribute
it with our XYZ product that needs a database."

Probably about 4 or so per day like this at present. A lot of the
people sending these emails appear to have windows based products that
need a database, and have heard of PostgreSQL being a database that they
don't need to pay license fee's for. They've kind of missed the point
of Open Source from the purist point of view, but it's still working for
them. ;-)

If they are:
a) not clueful enough to actually look at the license, and
b) looking at it from the purely selfish perspective of "not having to
pay license fees,"
then are they /truly/ people where it is useful to put effort into being
helpful?

Furthermore, if their lawyers are incapable of reading the license and
explaining to them "You don't have to pay," I'd suggest the thought that
maybe they have bigger problems than you can possibly solve for them.

The great security quote of recent days is thus:
"If you spend more on coffee than on IT security, then you will be
hacked." -- Richard Clarke

The analagous thing might be:

"If you spend more on coffee than you do on getting proper legal advice
about software licenses, then it's just possible that you might do
something DOWNRIGHT STUPID and get yourself in a whole barrel of legal
hot water."

If these people are incapable of reading software licenses, and haven't
any competent legal counsel to to do it for them, you've got to wonder
if they are competent to sell licenses to their own software. I
seriously doubt that they are.

Furthermore, I'm not at all sure that it is wise for you to even /try/
to give them any guidance in this, beyond giving them a URL to the
license, and saying "Have your lawyer read this." If you start giving
them interpretations of the license, that smacks of "giving legal
advice," and bar associations tend to frown on that.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne&gt; rate me
http://cbbrowne.com/info/
"Interfaces keep things tidy, but don't accelerate growth: functions
do." -- Alan Perlis

Cool irony in the automated .sig on the mailinglist software...

On Wed, 29 Jan 2003, Vince Vielhaber wrote:

...
hammering the betas is a far cry from an "industrial-strength solution".
...
TIP 4: Don't 'kill -9' the postmaster

Sounds like you're basically saying is

_do_ 'kill -9' the postmaster...

and make sure it recovers gracefully when testing for an "industrial-
strength solution".

Ron

Tom Lane wrote:

"Curtis Faith" <curtis@galtcapital.com> writes:

If a developer can simply download the source, click on the Visual C++
project in the win32 directory and then build PostgreSQL, and they can
see that Windows is not the "poor stepchild" because the VC project is
well laid out, they will be more likely to use it for Windows projects
than MySQL which requires the CygWin tools (this means "really a Unix
product" to Windows developers).

<flame on>
In all honesty, I do not *want* Windows people to think that they're not
running on the "poor stepchild" platform. If we go down that path,
they'll start trying to run production databases on Windows, and then
we'll get blamed for the instability of the platform, not to mention
the likelihood that it ignores Unix semantics for fsync() and suchlike
critical primitives.

Unless this concern is the result of experience (with, say, some
versions of Linux or whatnot), then I'd be more inclined to take a
"try it and see" attitude.

I do think it's quite appropriate to make the world aware that
PostgreSQL under Windows is not likely to be as dependable as
PostgreSQL under other Unix platforms, if only because the underlying
platform isn't as stable.

The fsync() issue and others like it can hopefully be settled through
testing. Frankly, I will be surprised if it doesn't work (but not
*too* surprised :-).

I have no objection to there being a Windows port that people can use
to do SQL-client development on their laptops. But let us please not
confuse this with an industrial-strength solution; nor give any level
of support that might lead others to make such confusion.

I don't believe the level of support this group provides has anything
to do with whether or not others will regard PostgreSQL on Windows to
be an industrial strength solution. Only their experience will
determine that. Because PostgreSQL doesn't have a huge marketing arm,
its reputation is built upon word of mouth, which is something that
only comes from experience.

You're assuming that if PostgreSQL is made available under Windows
such that it can be run as a service, people who deploy it will
immediately assume that it's an industrial strength solution. I think
that assumption is faulty, because in reality people out there in the
real world are reluctant to deploy PostgreSQL under *Unix* as an
industrial strength solution despite its high reliability. Otherwise
PostgreSQL would be a LOT more popular than it is.

It takes time and experience for people to be convinced that something
is industrial-strength, and the Windows port of PostgreSQL is no
exception.

Perhaps your real concern here is that a port of PostgreSQL to Windows
might negatively impact the overall reputation of PostgreSQL due to
the fragility of Windows. But I don't think that's really much of a
concern: I don't believe the overall reputation of Oracle suffered due
to its Windows port, for instance. I think most people who really
care about such things are aware that Windows as a platform isn't as
reliable as Unix and take that into account when judging the
reliability of a deployed solution.

For judging the reliability PostgreSQL under Windows, what would
matter would be how it stacks up against other database engines
running under Windows. In other words, take Windows out of the
comparison equation. If PostgreSQL under Windows is at least as fast,
solid, etc., as MS-SQL, DB/2, or Oracle under Windows, then people
will rightly think of PostgreSQL as an industrial-strength solution
and the reputation of PostgreSQL will be secure despite the failings
of the platform relative to Unix.

Bottom line: put tons of disclaimers about the likely reliability of
the Windows port in the documentation if you'd like, but don't let
these concerns prevent any action with respect to doing a proper
Windows port.

--
Kevin Brown kevin@sysexperts.com

On Wed, 29 Jan 2003, Ron Mayer wrote:

Cool irony in the automated .sig on the mailinglist software...

On Wed, 29 Jan 2003, Vince Vielhaber wrote:

...
hammering the betas is a far cry from an "industrial-strength solution".
...
TIP 4: Don't 'kill -9' the postmaster

Sounds like you're basically saying is

_do_ 'kill -9' the postmaster...

and make sure it recovers gracefully when testing for an "industrial-
strength solution".

Not what I said at all.

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: 30 January 2003 09:17
To: Ron Mayer
Cc: pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

On Wed, 29 Jan 2003, Ron Mayer wrote:

Cool irony in the automated .sig on the mailinglist software...

On Wed, 29 Jan 2003, Vince Vielhaber wrote:

...
hammering the betas is a far cry from an "industrial-strength
solution". ... TIP 4: Don't 'kill -9' the postmaster

Sounds like you're basically saying is

_do_ 'kill -9' the postmaster...

and make sure it recovers gracefully when testing for an

"industrial-

strength solution".

Not what I said at all.

It's not far off, but it's quite amusing none the less.

What I read from your postings it that you are demanding more rigourous
testing for a new major feature *prior* to it being comitted to CVS in a
dev cycle than I think we ever gave any previous new feature even in the
beta test phase. I don't object to testing, and have been thinking about
coding something to address Tom's concerns, but let's demand heavy
testing for the right reasons, not just to try to justify not doing a
Win32 port.

I would also point out that we already list the Cygwin port of
PostgreSQL as supported. Who ever gave that the kind of testing people
are demanding now? I think the worst case scenario will be that our
Win32 port is far better than the existing 'supported' solution.

Regards, Dave.

On Thu, 30 Jan 2003, Dave Page wrote:

On Wed, 29 Jan 2003, Ron Mayer wrote:

Cool irony in the automated .sig on the mailinglist software...

On Wed, 29 Jan 2003, Vince Vielhaber wrote:

...
hammering the betas is a far cry from an "industrial-strength
solution". ... TIP 4: Don't 'kill -9' the postmaster

Sounds like you're basically saying is

_do_ 'kill -9' the postmaster...

and make sure it recovers gracefully when testing for an

"industrial-

strength solution".

Not what I said at all.

It's not far off, but it's quite amusing none the less.

I agree with Tom on yanking the plug while it's operating. Do you
know the difference between kill -9 and yanking the plug?

What I read from your postings it that you are demanding more rigourous
testing for a new major feature *prior* to it being comitted to CVS in a
dev cycle than I think we ever gave any previous new feature even in the
beta test phase. I don't object to testing, and have been thinking about
coding something to address Tom's concerns, but let's demand heavy
testing for the right reasons, not just to try to justify not doing a
Win32 port.

Nice try. I've demanded nothing, quit twisting my words to fit your
argument. If you're going to test and call it conclusive, do some
conclusive testing or call it something else. But I suspect that since
you don't know the difference between yanking the plug and kill -9 this
conversation is a waste of time.

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

On Thu, 2003-01-30 at 13:24, Vince Vielhaber wrote:

On Thu, 30 Jan 2003, Dave Page wrote:

On Wed, 29 Jan 2003, Ron Mayer wrote:

Cool irony in the automated .sig on the mailinglist software...

On Wed, 29 Jan 2003, Vince Vielhaber wrote:

...
hammering the betas is a far cry from an "industrial-strength
solution". ... TIP 4: Don't 'kill -9' the postmaster

Sounds like you're basically saying is

_do_ 'kill -9' the postmaster...

and make sure it recovers gracefully when testing for an

"industrial-

strength solution".

Not what I said at all.

It's not far off, but it's quite amusing none the less.

I agree with Tom on yanking the plug while it's operating. Do you
know the difference between kill -9 and yanking the plug?

Kill -9 seems to me _less_ severe than yanking the plug but much easier
to automate, so that could be the first thing to test. You have no hope
of passing the pull-the-plug test if you can't survive even kill -9.

Perhaps we could have a special "reliability-regression" test that does
"kill -9 postmaster", repeatedly, at random intervals, and checks for
consistency ?

Maybe we will find even some options for some OS'es to "force-unmount"
disks. I guess that setting IDE disk's to read-only with hdparm could
possibly achieve something like that on Linux.

What I read from your postings it that you are demanding more rigourous
testing for a new major feature *prior* to it being comitted to CVS in a
dev cycle than I think we ever gave any previous new feature even in the
beta test phase. I don't object to testing, and have been thinking about
coding something to address Tom's concerns, but let's demand heavy
testing for the right reasons, not just to try to justify not doing a
Win32 port.

Nice try. I've demanded nothing, quit twisting my words to fit your
argument. If you're going to test and call it conclusive, do some
conclusive testing or call it something else.

So we have no conclusive testing done that /proves/ postgres to be
reliable ? I guess that such thing (positive conclusive reliability
test) is impossible even in theory.

But Dave has done some testing that could not prove the opposite and
concluded that it is good enough for him. So I guess that his test were
if fact "conclusive", if only just for him ;)

Sometimes it is very hard to do the pull-the-plug test - I've seen
people pondering over a HP server they could not switch off after
accidentally powering it up. Pulling the plug just made it beep, but did
not switch it off ;)

But I suspect that since
you don't know the difference between yanking the plug and kill -9 this
conversation is a waste of time.

I assume you realize that U can't "kill -9" the plug ;)

--
Hannu Krosing <hannu@tm.ee>

Hannu Krosing <hannu@tm.ee> writes:

Kill -9 seems to me _less_ severe than yanking the plug but much easier
to automate, so that could be the first thing to test. You have no hope
of passing the pull-the-plug test if you can't survive even kill -9.

Actually, they're two orthogonal issues.

In the pull-the-plug case you have to worry about what is on disk at any
given instant and whether you can make all the bits on disk consistent
again. (And also about whether your filesystem can perform the
equivalent exercise for its own metadata; which is why we are
questioning Windows here. Oracle's Windows port may have an advantage,
if they bypass the OS to do raw disk I/O as they do on other platforms.)

In the kill -9 case there is no risk of losing data consistency on disk,
because the OS isn't crashing; whatever we last wrote we can expect to
read. The issue for kill -9 is whether we can deal with leftover
dynamic state, like pre-existing shared memory segments, pre-existing
SysV semaphores, TCP port numbers that the kernel won't reassign until
some timeout expires, that kind of fun stuff. The reason the TIP is
still there is that there are platforms on which that stuff doesn't work
very nicely. It's better to let the postmaster exit cleanly so that
that state gets cleaned up. I have no idea what the comparable issues
are for a native Windows port, but I bet there are some...

regards, tom lane

"Dave Page" <dpage@vale-housing.co.uk> writes:

I would also point out that we already list the Cygwin port of
PostgreSQL as supported. Who ever gave that the kind of testing people
are demanding now? I think the worst case scenario will be that our
Win32 port is far better than the existing 'supported' solution.

A good point --- but what this is really about is expectations. If we
support a native Windows port then people will probably think that it's
okay to run production databases on that setup; whereas I doubt many
people would think that about the Cygwin-based port. So what we need to
know is whether the platform is actually stable enough that that's a
reasonable thing to do; so that we can plaster the docs with appropriate
disclaimers if necessary. Windows, unlike the other OSes mentioned in
this thread, has a long enough and sorry enough track record that it
seems appropriate to run such tests ...

regards, tom lane

On Thursday 30 January 2003 11:12, Tom Lane wrote:

A good point --- but what this is really about is expectations. If we
support a native Windows port then people will probably think that it's
okay to run production databases on that setup; whereas I doubt many
people would think that about the Cygwin-based port. So what we need to
know is whether the platform is actually stable enough that that's a
reasonable thing to do; so that we can plaster the docs with appropriate
disclaimers if necessary. Windows, unlike the other OSes mentioned in
this thread, has a long enough and sorry enough track record that it
seems appropriate to run such tests ...

I think it's just developer backlash to Win32. I am on record (see the
archives) as not wanting the Win32 port -- but the vitriol I've seen in this
thread from several people is entirely uncalled for and is sickening.

Dave appears to have tested this Win32 beta at least as much as a regular
PostgreSQL release would be tested. These tests are being held to
artificially high standards, simply because it's native Win32. That is
disgusting. And poor Katie just got _slammed_ -- and she's the lead
developer.

Vince, I would say that we, the developers of PostgreSQL, are then not
qualified to test our own releases for the reasons you mentioned that Katie
should not test her own releases. Of course that's ridiculous -- often the
developers can do a better job of testing because they know better than the
regular user would about what conditions can cause crashes.

I don't like the thoughts of native Win32 either. I think Win32 should die a
long horrible death. But that doesn't give me the right to publicly ridicule
the folks that want to use PostgreSQL, even if it's in an 'industrial
strength setting,' on Win32. The BSD license indemnifies us anyway. So
what's the problem.

The developers don't like Win32. That's the problem.

But as to 'industrial strength testing' -- do ANY of our releases get this
sort of testing on ANY platform? No, typically it's 'regression passed' 'Ok,
it's supported on that platform.'
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Hi,

On Thursday 30 January 2003 17:12, you wrote:

"Dave Page" <dpage@vale-housing.co.uk> writes:

I would also point out that we already list the Cygwin port of
PostgreSQL as supported. Who ever gave that the kind of testing people
are demanding now? I think the worst case scenario will be that our
Win32 port is far better than the existing 'supported' solution.

A good point --- but what this is really about is expectations. If we
support a native Windows port then people will probably think that it's
okay to run production databases on that setup; whereas I doubt many
people would think that about the Cygwin-based port. So what we need to
know is whether the platform is actually stable enough that that's a
reasonable thing to do; so that we can plaster the docs with appropriate
disclaimers if necessary. Windows, unlike the other OSes mentioned in
this thread, has a long enough and sorry enough track record that it
seems appropriate to run such tests ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Ah, well - I wanted to hold off but could not.

First, a disclaimer: I don't like Windows at all. There, you got it.

But: it's actually quite stable if you configure it well, and don't run the 3
million available 'dang, this looks nice' tools on it. Place it in the
corner, let it run only server apps, and it serves well and stable. In my
experience (and I have quite some experience in letting Win machines run in
heavy-duty 24/7 production floors) they will happily run and not eat data
until the some hardware breaks or disks overflow, just like any OS.

So, please, don't let a 'I don't like it' kind of flamewar hinder a native
port. And please no more 'not for production use' warnings - see above.
Make this 'not for production use on workstations'.

Greetings,
Joerg
--
Leading SW developer - S.E.A GmbH
Mail: joerg.hessdoerfer@sea-gmbh.com
WWW: http://www.sea-gmbh.com

On Thu, 30 Jan 2003, Lamar Owen wrote:

Vince, I would say that we, the developers of PostgreSQL, are then not
qualified to test our own releases for the reasons you mentioned that Katie
should not test her own releases. Of course that's ridiculous -- often the
developers can do a better job of testing because they know better than the
regular user would about what conditions can cause crashes.

Don't twist what I said. My statement about Katie was that she has a
knowledge of the port and the OS to the point where there are things
that she knows are wrong to do and would avoid doing it. In the case
of this port the idea is to make sure that those things that may cause
the backend to close are something that SHOULD be tested. By their own
admission they haven't been doing that. All they've done is loaded it
down and made sure it continued to work. The other ports have a long
history, the windows port has ZERO history. If you're being sickened
now, how sick would you be if something went wrong and you started seeing
things all over /. and other sites going on about how PG crashed and
blew away some corporation's data and half the OS away on something
that at worse should have only caused the backend to close? It won't
matter that it was running on windows, it would have been a native
port that was blessed by the PGDG.

If anything, the resistance to this testing should sicken you.

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

Lamar Owen <lamar.owen@wgcr.org> writes:

And poor Katie just got _slammed_ -- and she's the lead developer.

We could definitely do without the vitriol. I'd like to apologize if
anyone took anything I said as a personal attack. It wasn't meant that
way.

The developers don't like Win32. That's the problem.

Sure, we're on record as not liking Windows. But:

But as to 'industrial strength testing' -- do ANY of our releases get this
sort of testing on ANY platform? No, typically it's 'regression passed' 'Ok,
it's supported on that platform.'

Most variants of Unix are known to be pretty stable. Most variants of
Unix are known to follow the Unix standard semantics for sync() and
fsync(). I think we are entirely justified in doubting whether Windows
is a suitable platform for PG, and in wanting to run tests to find out.
Yes, we are holding Windows to a higher standard than we would for a
Unix variant.

Partly this is a matter of wanting to protect Postgres' reputation.
Just on sheer numbers, if there is a native Windows port then there are
likely to be huge numbers of people using Postgres on Windows. If
that's not going to be a reliable combination, we need to know it and
tell them so up-front. Otherwise, people will be blaming Postgres, not
Windows, when they lose data. It's an entirely different situation from
whether Postgres-on-Joe-Blow's-Unix-Variant loses data, first because of
visibility, and second because of the different user base. Am I being
paranoid to suspect that the average Postgres-on-Windows user will be
less clueful than the average Postgres-on-Unix user? I don't think so.

Between the population factors and Windows' hard-earned reputation for
unreliability, we would be irresponsible not to be asking tough
questions here. If the Windows partisans don't think Windows should be
held to a higher standard than the platforms we already deal with,
why not? Are they afraid that their platform won't pass the scrutiny?

regards, tom lane

On Thursday 30 January 2003 13:17, Vince Vielhaber wrote:

On Thu, 30 Jan 2003, Lamar Owen wrote:

Vince, I would say that we, the developers of PostgreSQL, are then not
qualified to test our own releases for the reasons you mentioned that
Katie should not test her own releases.

Don't twist what I said. My statement about Katie was that she has a
knowledge of the port and the OS to the point where there are things
that she knows are wrong to do and would avoid doing it.

Then she would not be honestly testing, would she?

admission they haven't been doing that. All they've done is loaded it
down and made sure it continued to work. The other ports have a long
history, the windows port has ZERO history.

Do we do powerfail testing on a unix-type port now? That's not testing the
port, incidentally, it's testing the OS, sync semantics aside. Do we hold
the other ports to the same standards? Yes, the Win32 port is a substantial
change from the Unix ports. Yes, it needs robust testing. But all the ports
need that same grade of testing, not just Win32. And that type of testing is
not being rigorously done on any port now, unless it is being done by a few
that aren't announcing that they are doing it.

And thanks to hardware write-back caching on many hard drives, powerfail
testing may be moot regardless of OS or filesystem type.

If you're being sickened
now, how sick would you be if something went wrong and you started seeing
things all over /. and other sites going on about how PG crashed and
blew away some corporation's data and half the OS away on something
that at worse should have only caused the backend to close?

Sick enough. But that applies to all our supported platforms, not just Win32.

From what I've seen and heard the 'supported' Cygwin port will barf all over

itself under high load. So, the first thing I personally would test for a
Win32 native port is 'how well is it performing under load?' -- after it
passes that I would then throw the more pathological cases at it.

It won't
matter that it was running on windows, it would have been a native
port that was blessed by the PGDG.

So? How many users out there actually know about the PGDG? How many users
have gotten PostgreSQL from their distributor of choice (whether a Linux
distribution, the Cygwin distribution, FreeBSD ports, or wherever) and know
nothing of PGDG or even postgresql.org? We make ourselves too important.

I know enough to take all those sites with a shakerful of salt. But then
again I know enough to know that the batboy didn't help Clinton or Bush do
anything, 'Weekly World News' aside. We can't prevent the tabloid mentality
regardless of what we do. Or don't do.

The point being that if any release of anything labeled 'PostgreSQL',
regardless of its status as blessed or not blessed (or even cursed) by the
PGDG, does what you've said, PostgreSQL as a whole will suffer. Our blessing
or cursing is meaningless to most users. Or, in slightly different words, if
they can't be bothered to care that it's on Windows then they aren't going to
care whether we gave it the Royal Seal of PGDG either.

However, I'm sure the folks that are wanting to sell this Win32 native port
care a whole lot about how much return business they get -- so I'm sure they
care more about whether it is robustly tested than you give them credit.

If anything, the resistance to this testing should sicken you.

There isn't any resistance to this testing that I've seen. ISTM that the
resistance is to the idea of a 'supported' WIn32 native port. So, let's test
the Win32 native beta using your scheme, and see what falls down. And let's
test Linux, *BSD, HP-UX, and AIX using the same scheme and see if it falls
down. Let's just be fair about the testing. The Win32 stuff is being
proclaimed as beta already -- so none are being misled into thinking it's
production grade right now. But it is passing those tests that hitherto have
been thrown at it -- and it seems to be passing them well.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Thu, 30 Jan 2003, Lamar Owen wrote:

On Thursday 30 January 2003 13:17, Vince Vielhaber wrote:

On Thu, 30 Jan 2003, Lamar Owen wrote:

Vince, I would say that we, the developers of PostgreSQL, are then not
qualified to test our own releases for the reasons you mentioned that
Katie should not test her own releases.

Don't twist what I said. My statement about Katie was that she has a
knowledge of the port and the OS to the point where there are things
that she knows are wrong to do and would avoid doing it.

Then she would not be honestly testing, would she?

She consider herself testing to her own standards as a windows user/
developer. Is that enough? IMO, No. I've been on both sides know
that the windows user/developer doesn't hold things to the same standards
as the unix user/developer.

admission they haven't been doing that. All they've done is loaded it
down and made sure it continued to work. The other ports have a long
history, the windows port has ZERO history.

Do we do powerfail testing on a unix-type port now? That's not testing the
port, incidentally, it's testing the OS, sync semantics aside. Do we hold
the other ports to the same standards? Yes, the Win32 port is a substantial
change from the Unix ports. Yes, it needs robust testing. But all the ports
need that same grade of testing, not just Win32. And that type of testing is
not being rigorously done on any port now, unless it is being done by a few
that aren't announcing that they are doing it.

Since you're pretty much ignoring my reasoning, I'll give you the same
consideration. The history of windows as a platform has shown itself
to be rather fragile compared to unix.

Before you respond to this, read Tom Lane's response and reply to that.

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

On Thursday 30 January 2003 13:34, Tom Lane wrote:

anyone took anything I said as a personal attack. It wasn't meant that
way.

With a <flame on> tag? Flames are by long tradition personal. But I
understand that that wasn't the intent -- the <flame on> was more of a
<emphasis> tag.

Sure, we're on record as not liking Windows. But:

But as to 'industrial strength testing' -- do ANY of our releases get
this sort of testing on ANY platform? No, typically it's 'regression
passed' 'Ok, it's supported on that platform.'

Most variants of Unix are known to be pretty stable. Most variants of
Unix are known to follow the Unix standard semantics for sync() and
fsync(). I think we are entirely justified in doubting whether Windows
is a suitable platform for PG, and in wanting to run tests to find out.

Testing is being done. Those who are testing it are comfortable so far in its
capabilities. We will hear about it, loadly, when that changes, I'm sure.

Yes, we are holding Windows to a higher standard than we would for a
Unix variant.

Which is pretty ironic, given Win's reputation, right?

Partly this is a matter of wanting to protect Postgres' reputation.

And here's where the rubber meets the road. We, like many developers of
software (open source and otherwise) have worked on this for so long and so
hard that we have personified the program and it has become our child, so to
speak. As a father of four, I know what that can do. We will protect our
child at any cost, vehemently so. I for one can recognize this, and further
recognize that _it's_just_a_program_ (!!!!!) and not my child. This is hard
to do. We're seeing our child experiment with what we consider to be bad
company, and the defense mechanism is kicking in.

Just on sheer numbers, if there is a native Windows port then there are
likely to be huge numbers of people using Postgres on Windows. If

While I understand (and agree with) your (and Vince's) reasoning on why
Windows should be considered less reliable, neither of you have provided a
sound technical basis for why we should not hold the other ports to the same
standards. I believe we should test every release as pathologically as Vince
has stated for Win32. The more reliable we become, the worse our test cases
should become. Across the board, and not just on Win32.

Do we want to encourage Win32? (some obviously do, but I don't) Well, telling
people that we have tested PostgreSQL on Win32 much more thoroughly than on
Unix is in a way telling them that we think it is _better_ than the
time-tested Unix ports ('It passed a harder test on Win32. Are we afraid the
Unix ports won't pass those same tests?'). I for one don't want that to be a
conclusion -- but the 'suits' will see it that way, rest assured.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From: "Tom Lane" <tgl@sss.pgh.pa.us>

Most variants of Unix are known to be pretty stable. Most variants of
Unix are known to follow the Unix standard semantics for sync() and
fsync(). I think we are entirely justified in doubting whether Windows
is a suitable platform for PG, and in wanting to run tests to find out.
Yes, we are holding Windows to a higher standard than we would for a
Unix variant.

The patches that were released implement fsync() by a call to _commit(),
which is what I expected to see after a brief tour of the M$ support site.
Is there any reason to think this won't have the desired effect? IANAWD, but
my reading suggests these should be pretty much equivalent.

andrew

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: 30 January 2003 19:20
To: Lamar Owen
Cc: Tom Lane; Dave Page; Ron Mayer; pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

I've
been on both sides know that the windows user/developer
doesn't hold things to the same standards as the unix user/developer.

I ought to plonk you for a comment like that. Especially coming from the
person who's crap I've been trying to sort out for the last couple of
months.

Since you're pretty much ignoring my reasoning, I'll give you
the same consideration. The history of windows as a platform
has shown itself to be rather fragile compared to unix.

When properly configured, Windows can be reliable, maybe not as much as
Solaris or HPUX but certainly some releases of Linux (which I use as
well). You don't see Oracle or IBM avoiding Windows 'cos it isn't stable
enough.

Before you respond to this, read Tom Lane's response and
reply to that.

*I* did. I volunteered to do some more of the testing we're all so
resistant.

Dave.

On Thu, 30 Jan 2003, Dave Page wrote:

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: 30 January 2003 19:20
To: Lamar Owen
Cc: Tom Lane; Dave Page; Ron Mayer; pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

I've
been on both sides know that the windows user/developer
doesn't hold things to the same standards as the unix user/developer.

I ought to plonk you for a comment like that. Especially coming from the
person who's crap I've been trying to sort out for the last couple of
months.

Grow up Dave. That shit doesn't belong on this or any other list. If
you didn't want to do something, you shouldn't have volunteered to do it.

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 30 January 2003 15:56
To: Hannu Krosing
Cc: Vince Vielhaber; Dave Page; Ron Mayer;
pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

In the pull-the-plug case you have to worry about what is on
disk at any given instant and whether you can make all the
bits on disk consistent again. (And also about whether your
filesystem can perform the equivalent exercise for its own
metadata; which is why we are questioning Windows here.

I've never (to my knowledge) lost any data following a powerfail or
system crash on a system using NTFS - that has always seemed pretty
solid to me. By comparison, I have lost data on ext2 filesystems on a
couple of occasions.

More info at:

http://www.ntfs.com/data-integrity.htm
http://www.pcguide.com/ref/hdd/file/ntfs/relRec-c.html

Obviously this goes out of the window is the user chooses to run on
FAT/FAT32 partitions. I think that it should be made *very* clear in any
future documentation that the user is strongly advised to use only NTFS
filesystems.

I realise this is not proof that it actually works of course...

Regards, Dave.

Lamar Owen <lamar.owen@wgcr.org> writes:

While I understand (and agree with) your (and Vince's) reasoning on why
Windows should be considered less reliable, neither of you have provided a
sound technical basis for why we should not hold the other ports to the same
standards.

The point here is that Windows is virgin territory for us. We know
about Unix. When we port to a new Unix variant, we are dealing with the
same system APIs, and in many cases large chunks of the same system
code, that we've dealt with before. It's reasonable for us to have
confidence that Postgres will work the same on such a platform as it
does on other Unix variants. And the track record of reliability that
we have built up across a bunch of Unix variants gives us
cross-pollinating confidence in all of them.

Windows shares none of that heritage. It is the first truly new port,
onto a system without any Unix background, that we have ever done AFAIK.
Claiming that it doesn't require an increased level of testing is
somewhere between ridiculous and irresponsible.

I believe we should test every release as pathologically as Vince
has stated for Win32.

Great, go to it. That does not alter the fact that today, with our
existing port history, Windows has to be treated with extra suspicion.

I do not buy the argument you are making that we should treat all
platforms alike. If we had a ten-year-old Windows port, we could
consider it as stable as all our other ten-year-old Unix ports.
We don't. Given that we don't have infinite resources for testing,
it's simple rationality to put more testing emphasis on the places
that we suspect there will be problems. And if you don't suspect
there will be problems on Windows, you are being way too naive :-(

Do we want to encourage Win32? (some obviously do, but I don't) Well, telling
people that we have tested PostgreSQL on Win32 much more thoroughly than on
Unix is in a way telling them that we think it is _better_ than the
time-tested Unix ports ('It passed a harder test on Win32. Are we afraid the
Unix ports won't pass those same tests?').

If it passes the tests, good for it. I honestly do not expect that it
will. My take on this is that we want to be able to document the
problems in advance, rather than be blindsided.

regards, tom lane

"Dave Page" <dpage@vale-housing.co.uk> writes:

I've never (to my knowledge) lost any data following a powerfail or
system crash on a system using NTFS ...
Obviously this goes out of the window is the user chooses to run on
FAT/FAT32 partitions. I think that it should be made *very* clear in any
future documentation that the user is strongly advised to use only NTFS
filesystems.

This is exactly the kind of thing we have to learn about and document.
Which Windows releases can be trusted, which filesystems are okay,
what other stuff do you need to stay away from?

regards, tom lane

Dave, Lamar and Katie can cheer now 'cuze this is the last comment
I'm going to make on this. All others will be ignored, probably.

The one thing I haven't seen from Dave, Lamar or Katie on this is
reputation. You're all for the PostgreSQL name going on it but I
have yet to see any of you so sure of yourselves that you'd put
your own name on it. The license allows it. Red Hat did it. I
see no "PageSQL" or "KatieSQL" or even an "Oh-Win SQL" being offered
up. Yet all three of you are advocating that the PostgreSQL stamp
of approval should be immediately placed on it (ok, Lamar may not
be as in favor as the Dave and Katie).

Without documented testing and sufficient warnings until enough
history is banked, I don't think a native windows port should be
given any kind of seal of approval. After that, what about keeping
the code current? In a year or so will it suffer from bit-rot and
be the source of complaints? Are there going to be security concerns
surrounding it? Is there going to be a bunch of scrambling going on
to put out a patch when the latest active-x bug hoses the data dir?

Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

Vince Vielhaber <vev@michvhf.com> writes:

Without documented testing and sufficient warnings until enough
history is banked, I don't think a native windows port should be
given any kind of seal of approval.

That was my last point also: we have years of track record on most of
our Unix ports, and none yet on Windows. Even several months of
intensive testing by a small number of people will hardly level the
playing field.

After that, what about keeping the code current?

I don't think that's an issue. We are not blessing anything based on
7.2 ;-). The objective is to merge the changes into CVS tip and have
a first "official" Windows port as part of the 7.4 release. After that,
it'll stay as current as any other port that's being actively used.

regards, tom lane

On Thursday 30 January 2003 15:29, Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

While I understand (and agree with) your (and Vince's) reasoning on why
Windows should be considered less reliable, neither of you have provided

Windows shares none of that heritage. It is the first truly new port,
onto a system without any Unix background, that we have ever done AFAIK.
Claiming that it doesn't require an increased level of testing is
somewhere between ridiculous and irresponsible.

I am saying that as we mature we need increased testing across the board. And
it is a very low percentage of code that is tied into the OS API, right? The
majority of the code (the vast majority) isn't touched by it.

that we suspect there will be problems. And if you don't suspect
there will be problems on Windows, you are being way too naive :-(

Reread my statement above. I _agree_ with the rationale -- but I fear it will
have the opposite impact. And I am not convinced that just because we have
good history with the unixoid ports means that we can slack on them -- Linux,
*BSD, etc all change. The strftime(3) breakage with RedHat of a cycle ago
should show us that much.

I suspect there will be problems on Win32 -- it is, after all, a new port.
But if we're going to immediately throw pathological test cases at it that
we're not even bothering to test against now, that immediately throws up a
flag to me. And TESTING IS BEING DONE on the Win32 port, nobody is yet
trying to put the PGDG blessing on it as yet, and progress is being made by
those who wish to see it made. It is still being touted as beta software,
right? The patches from Jan are very preliminary still, correct? Katie
hasn't issued a press release saying that it's not beta, right?

<hyperbole>
I don't see what the uproar is about, other than 'Win32 is so unstable that it
can't possibly work as well as you are seeing it work -- you must be doing
something wrong. Test it harder. Pull the plug repeatedly!! Test it until
it breaks! HA! Told you it would break! (yeah, firing up the old
oxyacetlyene torch and hitting the hard drive with a 6,000 degree flame did
the trick -- this has got to be a bad operating system!)'
</hyperbole>

And, by the way, who in their right mind tests a database server by repeated
yanking of the AC power? To go to that extreme for Win32 when we caution
against something as mundane as a kill -9 of postmaster on Unix is absurd.
And, yes, I know the difference. I also know that the AC power pull has
nothing to do with PostgreSQL, but it has to do with the OS under it.
Although a kill -9, from the point of view of the running process, is
identical to a power failure. It simply dies (unless it becomes a zombie, in
which case it is undead) either way. The effects of a kill -9 shouldn't be
as severe as a power fail, since the OS can properly flush written buffers
even after the process writing them has died.

And I also can point the finger at some Unix swervers (spelling intentional)
that would fail that test in a miserable way. I can also point at a few VMS
machines that couldn't pass that test. I've even seen machines blow up due
to improper power cycling.

And I've seen Win2k machines come right up after repeated power blips (I've
also seen them not come up).

It really depends upon what the hard disk is doing at the instant the
regulators drop out the 5 and 12V supplies (and which supply goes out first,
which can depend upon the respective loads -- for modern Pentium 4 systems
the 12V will probably go down first since it is more heavily loaded than the
5V supply in these systems). Under certain conditions where the 12V goes
down before the 5V does, the head might still be writing as the servo spirals
towards park, causing all manner of damage (maybe even to servo information,
which normally cannot be written). So the power cycle becomes a test of
hardware, too, played Russian Roulette-style.

Talk about an unscientific test.

A database server that needs that kind of testing is going to be hardened
hardware on a doubly redundant UPS anyway.

But, then again I've seen a Linux server survive a power cycle with no lost
data (ext3 filesystem -- I've seen lost data with ext2). And I've seen the
same server barf all over itself due to a single bit error in memory. Blew
out the entire root filesystem, which was journaled and residing on a RAID 1
partition (the corruption was perfectly mirrored, by the way). Serves me
right for not having ECC RAM installed at the time.

If it passes the tests, good for it. I honestly do not expect that it
will. My take on this is that we want to be able to document the
problems in advance, rather than be blindsided.

I fully expect that Katie, Jan, Dave, and all the others working on this share
your concerns and want the Win32 port to be as solid as is possible on that
OS.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Thursday 30 January 2003 16:01, Vince Vielhaber wrote:

Dave, Lamar and Katie can cheer now 'cuze this is the last comment
I'm going to make on this. All others will be ignored, probably.

up. Yet all three of you are advocating that the PostgreSQL stamp
of approval should be immediately placed on it (ok, Lamar may not
be as in favor as the Dave and Katie).

For the record, again, I am not at all in favor of a Win32 native port. I
have never been in favor of a Win32 native port (see the archives -- it's in
there). I am in favor of fair testing for all ports, and less of an
emotional response to the idea of a Win32 port. It's going to happen; we
can't stop it; we might as well see how best to handle it.

And I am definitely not in favor of putting the Royal Seal of PGDG on the code
that is out there now. It _isn't_ proven. And, as Tom just said, it's 7.2,
and we're not due to make an Officially Stamped Win32 native port until 7.4.

But it doesn't take AC power cycling to prove it, either. And so I objected
to the tone and to the extremity of the proposed testing, relative to the
testing we do now for the other ports.

But I also see the futility of withholding the Official Stamp of Approval --
if Win32 PostgreSQL is out there (and it will be, whether we like it or not),
then we will get flak over it if it breaks. Logically we should do
everything we can to make sure the port is as stable as possible for Win32 --
and power cycle testing ain't the right way. ISTM that Dave, Katie, Jan, et
all are doing this. They even seem to know what they are talking about,
which is better than most Win32 partisans. There actually _can_ be
reasonable people who use an unreasonable OS, for whatever reasons they may
have.

Do I like it? No. Can I change it? No. Can I help test the Win32 port? Yes,
even though I don't want to do so. Can I be reasonable and patient with
those who are doing the work on the Win32 port? Yes, I can. Do I need to
sling the napalm because I don't like it? Not on the mailing lists (hmm,
need to get some naptha, some palmitic acid....might be fun to sling some
napalm in the back yard to rid the place of weeds, and get some relaxation to
boot....).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

And, by the way, who in their right mind tests a database server by repeated
yanking of the AC power?

Anybody who would like their data to survive a power outage.

To go to that extreme for Win32 when we caution
against something as mundane as a kill -9 of postmaster on Unix is absurd.
And, yes, I know the difference. I also know that the AC power pull has
nothing to do with PostgreSQL, but it has to do with the OS under it.
Although a kill -9, from the point of view of the running process, is
identical to a power failure.

No, it is not. Did you not read my comments earlier today? The reasons
why we are concerned about kill -9 have *nothing* to do with whether the
database can survive system crashes. Rather, the issues created by kill
-9 have to do with coping with leftover state from a previous postmaster
in the same system lifecycle. I forgot to mention one of the biggest
headaches, which is that kill -9 the postmaster doesn't kill the child
backends. We've got an interlock that tries to prevent starting a new
postmaster when there are still old children around, but it's one of the
things that I think is most likely to break on any new port. (And I'm
dead certain that that code doesn't work on Windows.) It's that sort of
thing that we have painfully worked out on Unix-based systems, and are
going to have to do over again for Windows. In many places we are
probably not even going to realize that we have to do something over
again, until someone gets bitten.

The fact that Postgres is reliable does not come (only) from the code
being "right" in some abstract sense that will carry over to a new
platform. A big reason it's reliable is that we have painfully learned
about Unix-ish failure modes and put in defenses against them. Windows
is going to bring a whole new set of failure modes that we don't have
defenses for. (Yet.) *That* is what we need extensive testing to learn
about, and claiming that we are discriminating against Windows just
because it's Windows misses the point completely.

Or, if you prefer, we can ship Postgres 7.4 for Windows with no more
testing than we need for any of the existing, long-since-well-tested
ports. But I'll bet a great deal that our reputation will go down the
drain (along with many people's data) if we do that.

regards, tom lane

On Thursday 30 January 2003 16:54, Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

And, by the way, who in their right mind tests a database server by
repeated yanking of the AC power?

Anybody who would like their data to survive a power outage.

I don't buy that. That's why I have $36,000 worth of lead acid in the room
next door, with $5,000 of inverters and chargers in the server room. Until I
had to upgrade RAM I had 240+ days of uptime on one box. The longest power
interruption was 28 hours. The battery held the whole time. There was never
more than 30 days between interruptions. The last time I had the server
actually power down was during a maintenance run on the inverter/charge
system, and I had to transfer power to the servers onto another branch,
necessitating two power cycles, which were clean shutdown/reboots. I haven't
had an unscheduled dirty powerdown in two years.

We cannot on any system guarantee the data surviving a sudden power outage.
Until we can be certain the write-back cache on that high performance drive
(or NAS array using iSCSI, perhaps) flushes we cannot know the data hit the
disks.

To go to that extreme for Win32 when we caution
against something as mundane as a kill -9 of postmaster on Unix is
absurd. And, yes, I know the difference. I also know that the AC power
pull has nothing to do with PostgreSQL, but it has to do with the OS
under it. Although a kill -9, from the point of view of the running
process, is identical to a power failure.

No, it is not. Did you not read my comments earlier today?

Of course I did -- I'm not daft. And that's why I specified 'from the point
of view of the running process' -- that is, the process you are SIGKILLing
cannot itself determine the difference between the power cycle and SIGKILL.
It just simply goes down, hard. Of course there is:

I forgot to mention one of the biggest
headaches, which is that kill -9 the postmaster doesn't kill the child
backends.

This is a real difference, and one that I forgot as well. So SIGKILL is
different to the whole backend system, but not to the singular process that
is being SIGKILL'd. Suppose I issue a SIGKILL to postmaster and all forked
backends simultaneously? Where does SIGKILL differ from a power failure from
the point of view of the database system in that scenario? This is also
assuming that you clean reboot the OS after the SIGKILL to postmaster, as
there is that dynamic state you mentioned to worry about. I probably should
have mentioned that before.

Windows
is going to bring a whole new set of failure modes that we don't have
defenses for. (Yet.) *That* is what we need extensive testing to learn
about, and claiming that we are discriminating against Windows just
because it's Windows misses the point completely.

And ISTM that an experienced Windows developer, such as Katie or Dave, would
know to do this, would know how to do this, and would know the best way of
doing this. And I wasn't singling you out, Tom. It was the whole thread and
the turns it took that got me rather upset.

Or, if you prefer, we can ship Postgres 7.4 for Windows with no more
testing than we need for any of the existing, long-since-well-tested
ports. But I'll bet a great deal that our reputation will go down the
drain (along with many people's data) if we do that.

We don't have a standard testing methodology for any of our ports. We need
one for all of our ports. I fully expect the Win32 port to need a different
methodology than the FreeBSD port or the Linux port. And I expect we have
enough experienced Win32 developers (which I am not) here that can provide
insight into how the methodologies should differ.

I prefer more extensive testing for all of our ports. You did read that when
I wrote it, right? (When I wrote it multiple times....) Just saying 'it
passed regression' shouldn't be enough -- but we should really spend some
cycles thinking about what the test suite really should be. For all
platforms.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Thu, 2003-01-30 at 13:56, Dave Page wrote:

When properly configured, Windows can be reliable, maybe not as much as
Solaris or HPUX but certainly some releases of Linux (which I use as
well). You don't see Oracle or IBM avoiding Windows 'cos it isn't stable
enough.

I'm not jumping on one side or the other but I wanted to make clear on
something. The fact that IBM or Oracle use windows has absolutely zero
to do with reliability or stability. They are there because the market
is willing to spend money on their product. Let's face it, the share
holders of each respective company would come unglued if the largest
software audience in the world were completely ignored.

Simple fact is, your example really is pretty far off from supporting
any view. Bluntly stated, both are in that market because they want to
make money; they're even obligated to do so.

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

Tom Lane wrote:

"Dave Page" <dpage@vale-housing.co.uk> writes:

I would also point out that we already list the Cygwin port of
PostgreSQL as supported. Who ever gave that the kind of testing people
are demanding now? I think the worst case scenario will be that our
Win32 port is far better than the existing 'supported' solution.

A good point --- but what this is really about is expectations. If we
support a native Windows port then people will probably think that it's
okay to run production databases on that setup;

Sure. But it's only common sense that a piece of software is only as
reliable as the platform it's running on.

People run production databases under MS-SQL all the time. Has MS-SQL
itself gained a reputation for being an unreliable piece of junk?
Perhaps. But if so, that obviously hasn't stopped people from putting
their production databases on it!

Is MS-SQL's reputation for unreliability, if any, because of MS-SQL
itself or the platform it's operating on? The way to answer that is
to ask the same question of Oracle and DB/2 under Windows. And
therefore, the answer seems to be that the platform is a minor
determinant, if any.

whereas I doubt many
people would think that about the Cygwin-based port.

Why not? Seriously, if the people in question are the simpletons that
you appear to be expecting them to be, then wouldn't they have that
same expectation of the Cygwin based port? Why not?

So what we need to
know is whether the platform is actually stable enough that that's a
reasonable thing to do; so that we can plaster the docs with appropriate
disclaimers if necessary.

Well, shouldn't we do that anyway, then, until we know otherwise?
Shouldn't we do that with *any* new port?

Windows, unlike the other OSes mentioned in
this thread, has a long enough and sorry enough track record that it
seems appropriate to run such tests ...

With this I agree, but before you start thinking that Windows is the
only OS that qualifies, consider this: I've run the "pull the plug"
test under early Linux 2.4 kernels running with ReiserFS. I'd start a
make of a large project, pull the power, bring the system back up, and
restart the build. And the end result was that some of the files
files in the build directory were corrupted, such that the build could
not continue. I haven't tried this under current versions of the
kernel, so I don't know if things have improved or not.

Doesn't that -- shouldn't that -- give you pause about declaring
*Linux* an industrial-strength solution?

My point: if you're going to hold *one* OS to a given standard, you
should hold *all* of them to that same standard.

--
Kevin Brown kevin@sysexperts.com

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Thursday, January 30, 2003 12:30 PM
To: Lamar Owen
Cc: Dave Page; Vince Vielhaber; Ron Mayer;
pgsql-hackers@postgreSQL.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

Lamar Owen <lamar.owen@wgcr.org> writes:

While I understand (and agree with) your (and Vince's) reasoning on
why
Windows should be considered less reliable, neither of you

have provided a

sound technical basis for why we should not hold the other

ports to the same

standards.

The point here is that Windows is virgin territory for us.
We know about Unix. When we port to a new Unix variant, we
are dealing with the same system APIs, and in many cases
large chunks of the same system code, that we've dealt with
before. It's reasonable for us to have confidence that
Postgres will work the same on such a platform as it does on
other Unix variants. And the track record of reliability
that we have built up across a bunch of Unix variants gives
us cross-pollinating confidence in all of them.

Windows shares none of that heritage. It is the first truly
new port, onto a system without any Unix background, that we
have ever done AFAIK. Claiming that it doesn't require an
increased level of testing is somewhere between ridiculous
and irresponsible.

I believe we should test every release as pathologically as Vince
has stated for Win32.

Great, go to it. That does not alter the fact that today,
with our existing port history, Windows has to be treated
with extra suspicion.

I do not buy the argument you are making that we should treat
all platforms alike. If we had a ten-year-old Windows port,
we could consider it as stable as all our other ten-year-old
Unix ports. We don't. Given that we don't have infinite
resources for testing, it's simple rationality to put more
testing emphasis on the places that we suspect there will be
problems. And if you don't suspect there will be problems on
Windows, you are being way too naive :-(

Do we want to encourage Win32? (some obviously do, but I

don't) Well,

telling
people that we have tested PostgreSQL on Win32 much more

thoroughly than on

Unix is in a way telling them that we think it is _better_ than the
time-tested Unix ports ('It passed a harder test on Win32.

Are we afraid the

Unix ports won't pass those same tests?').

If it passes the tests, good for it. I honestly do not
expect that it will. My take on this is that we want to be
able to document the problems in advance, rather than be blindsided.

Our port of 7.1.3 passed every test, including the dynamic loading.

I don't expect the Win32 port to be problematic.

On Thu, 2003-01-30 at 14:27, Dave Page wrote:

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 30 January 2003 15:56
To: Hannu Krosing
Cc: Vince Vielhaber; Dave Page; Ron Mayer;
pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

In the pull-the-plug case you have to worry about what is on
disk at any given instant and whether you can make all the
bits on disk consistent again. (And also about whether your
filesystem can perform the equivalent exercise for its own
metadata; which is why we are questioning Windows here.

I've never (to my knowledge) lost any data following a powerfail or
system crash on a system using NTFS - that has always seemed pretty
solid to me. By comparison, I have lost data on ext2 filesystems on a
couple of occasions.

More info at:

http://www.ntfs.com/data-integrity.htm
http://www.pcguide.com/ref/hdd/file/ntfs/relRec-c.html

Obviously this goes out of the window is the user chooses to run on
FAT/FAT32 partitions. I think that it should be made *very* clear in any
future documentation that the user is strongly advised to use only NTFS
filesystems.

I realise this is not proof that it actually works of course...

I have lost entire directory trees (and all associated data) on NTFS
before. NTFS was kind enough to detect an inconsistency during boot and
repaired the file system by simply removing any and all references to
the top level damaged directory (on down). Sure, the file system was in
a known good state following the repair but the 2-days to recover from
it, pretty much stunk!

I would also like to point out that this damage/repair occurred on a
RAID-5 box (hardware, not software). As the repairs placed the file
system back into known good state, the raid hardware was happy to obey.
Guess what, it did! :( Make no mistake about it. You can easily lose
large amounts of data on NTFS.

You also compared NTFS with ext2. That's not exactly fair. Better you
should compare NTFS with ext3, XFS, JFS, ReiserFS. It's a better, more
fair comparison, as now we're talking about the same category of file
system.

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

Greg Copeland wrote:

On Thu, 2003-01-30 at 13:56, Dave Page wrote:

When properly configured, Windows can be reliable, maybe not as much as
Solaris or HPUX but certainly some releases of Linux (which I use as
well). You don't see Oracle or IBM avoiding Windows 'cos it isn't stable
enough.

I'm not jumping on one side or the other but I wanted to make clear on
something. The fact that IBM or Oracle use windows has absolutely zero
to do with reliability or stability. They are there because the market
is willing to spend money on their product. Let's face it, the share
holders of each respective company would come unglued if the largest
software audience in the world were completely ignored.

Simple fact is, your example really is pretty far off from supporting
any view. Bluntly stated, both are in that market because they want to
make money; they're even obligated to do so.

That's true, but it ignores the question that makes it relevant: has
their appearance in the Windows market tarnished their reputation?
More precisely, has it tarnished their reputation in the *Unix*
community? The answer, I think, is no.

And that *is* relevant to us, because our concern is about the
reputation of PostgreSQL, and what will happen to it if we release a
native Windows port to the world.

Of course, you could argue that Oracle and IBM didn't have much of a
reputation anyway, and I wouldn't be able to say much to that. :-)

--
Kevin Brown kevin@sysexperts.com

On Thu, Jan 30, 2003 at 02:39:59PM -0800, Kevin Brown wrote:

With this I agree, but before you start thinking that Windows is the
only OS that qualifies, consider this: I've run the "pull the plug"
test under early Linux 2.4 kernels running with ReiserFS. I'd start a
make of a large project, pull the power, bring the system back up, and
restart the build. And the end result was that some of the files
files in the build directory were corrupted, such that the build could
not continue.

Afaik, ReiserFS does not guarantee data consistency, only meta
data. As in, the file system itself will be consistent, and an
fsck shouldn't find a problem.

Kurt

Kurt Roeckx wrote:

On Thu, Jan 30, 2003 at 02:39:59PM -0800, Kevin Brown wrote:

With this I agree, but before you start thinking that Windows is the
only OS that qualifies, consider this: I've run the "pull the plug"
test under early Linux 2.4 kernels running with ReiserFS. I'd start a
make of a large project, pull the power, bring the system back up, and
restart the build. And the end result was that some of the files
files in the build directory were corrupted, such that the build could
not continue.

Afaik, ReiserFS does not guarantee data consistency, only meta
data. As in, the file system itself will be consistent, and an
fsck shouldn't find a problem.

Exactly. Does NTFS? Not as far as I know. Why should we hold NTFS
to a standard that ReiserFS doesn't meet?

That said, I do agree with Tom that the Windows port is basically
virgin territory and needs to be approached with caution. But we
shouldn't be so cautious that we hesitate to release the port to the
world (sufficient disclaimers are appropriate, as with any new
port)...

--
Kevin Brown kevin@sysexperts.com

Lamar Owen <lamar.owen@wgcr.org> writes:

On Thursday 30 January 2003 16:54, Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

And, by the way, who in their right mind tests a database server by
repeated yanking of the AC power?

Anybody who would like their data to survive a power outage.

I don't buy that. That's why I have $36,000 worth of lead acid in the room
next door, with $5,000 of inverters and chargers in the server room.

Well, great; you're probably proof against misfeasance of your local
power company. But how about someone tripping over the power cord?
Or a blowout in the server's internal power supply? Or a kernel crash?
Pulling the power plug is just a convenient way of (approximately)
modeling a whole class of unpleasant events. I don't think the fact
that you can afford to spend that much on batteries makes it
uninteresting to test such scenarios.

But we're pretty much talking at cross-purposes here. The real issue
IMHO is that the Windows port needs a lot of testing because it is a
new platform (for us), and one not like the platforms we've used before.
It is faulty to equate the amount of testing required to gain confidence
in that port with the amount of testing required to gain confidence that
PG 7.4 will run reliably on, say, HPUX 10.20, when we already know that
every PG back to 6.4 has run reliably on HPUX 10.20. You're attacking a
straw man you have set up, namely the idea that only specific testing
produces confidence in a port. In my mind past track record has a lot
more to do with confidence than whatever testing we do for an individual
release.

regards, tom lane

On Thursday 30 January 2003 18:39, Tom Lane wrote:

Well, great; you're probably proof against misfeasance of your local
power company. But how about someone tripping over the power cord?

Twistlok.

Or a blowout in the server's internal power supply?

Redundant supplies.

Or a kernel crash?

Different from pulling the plug.

It is faulty to equate the amount of testing required to gain confidence
in that port with the amount of testing required to gain confidence that
PG 7.4 will run reliably on, say, HPUX 10.20, when we already know that
every PG back to 6.4 has run reliably on HPUX 10.20.

But does the fact that PG 6.4 ran reliably on HP-UX 10 mean PG 7.4 will run as
reliably on HP-UX 11? Does the fact that PG 6.2.1 ran well on Linux kernel
2.0.30 with libc 5.3.12 mean PG 7.4 will run well on Linux 2.6.x with glibc
2.4.x? The OS is also a moving target. Hmph. PG 7.3 won't even build on
Red Hat 5.2, for instance. So much for track record.

You're attacking a
straw man you have set up, namely the idea that only specific testing
produces confidence in a port. In my mind past track record has a lot
more to do with confidence than whatever testing we do for an individual
release.

Track record means nothing if sufficient items have changed in the underlying
OS. I remember the Linux fiasco with PostgreSQL 6.3.1. It was so bad that
Red Hat was considering releasing Red Hat 5.1 with a CVS checkout of
pre-6.3.2. That is not Red Hat's normal policy.

Also, between major versions enough may have changed to make it necessary to
test thoroughly -- WAL, for instance. MVCC for another instance. PITR is
going to be another instance requiring a different test methodology. One
will indeed be required to blow down the whole system to properly test PITR,
on all platforms.

Track record indicates that all of our x.y.1 releases are typically hosed in
some fashion. 7.3.1 proved that wrong. Track record only requires a single
failure to invalidate -- and we should test for those failures across the
board, regardless of track record. Records are meant to be broken.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Vince Vielhaber wrote:

On Wed, 29 Jan 2003, Dave Page wrote:

hammering the betas is a far cry from an "industrial-strength
solution".

Have you a better suggestion? Seems a bit catch 22 if testing won't
prove it's good and we can't use it until we know it's good... Still,
industrial strength testing or not, it's more reliable than the SQL 2000
and DB2 installations I have here.

Well you have a beta running, load it up with data and let a few hundred
clients loose on it. I've seen win2k BSOD with less stress than that.

You have what? I have "never" seen a Win2K *production* system throwing
a bluescreen that was not caused by a hardware fault. And if the systems
you are referring to have any of this

- soundcard
- "state OFF the art" graphics adapter
- joystuck or gamepet
- ACPI HAL

you aren't talking about production systems and just disqualified the
probably highly overpaid IDIOT who installed them. Highly overpaid
because if he got more than the negative of the project cost, it was too
much.

What I see reading this thread is the typical "release early" problem.
People have tried Windows 3.1, they "know" Windows is crap ... from
experience! People have had problems with Windows NT 3.51 and "know"
Windows NT is crap ... from experience! I don't exclude myself from that
group, I had tried MS-DOS 3.21 and I "knew" Microsoft OS's are crap ...
from experience! It took 15 years and some serious multi-million
projects before I reevaluated my opinion.

Windows 2000 by itself is an industrial strength, stable operating
system. Don't let it get in touch with hard- and software your server
doesn't need, give it the hardware your business deserves, and you'll
have a robust and reliable system you can trust.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Dave Page wrote:

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 29 January 2003 16:57
To: Dave Page
Cc: Vince Vielhaber; Katie Ward; Curtis Faith;
pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

"Dave Page" <dpage@vale-housing.co.uk> writes:

I'll admit my methods were not particularly scientific, but

over the

last few weeks I've had far more grief from DB2 and SQL

Server than I

did from the PostgreSQL native betas.

My gripe had to do with questioning the reliability of the
platform, not of the Postgres port ;-).

Aside from load testing as suggested by Vince, I'd be
interested to hear what happens when you pull the power cord
under load (repeatedly). This would give some evidence about
the robustness of the Windows filesystem and its ability to
emulate Unix sync semantics.

OK, I can maybe do some testing on that next week (I'm off for a few
days from today). Is there anything in particular I should look out for,
or that you would want tested?

Katie, can I get the latest build from anywhere?

The code Katie wrote and tested, and what has been posted by me are two
different things. So what has been posted might not be that solid as a
rock as the beta's you got from PeerDirect. I will try to put some
binaries of what I posted together over the weekend.

That said, I don't quite understand the attitude of some people here. Is
it that if the native Win32 port as I posted it isn't as solid and
stable as v7.3 on Unix (well, some flavours), we will have to reject it?
With that ruleset (ruleset, what a word in this context ;-) we would not
have an SQL parser yet ...

Also, so far I have the impression not many people have actually taken a
look at the code itself. Everyone is busy bitching about the build
environment and if it is kosher to cook the code in Cygwin milk on a
Microsoft stove or not. Sorry guy's, but that's not the point! Does
anyone feel that the quality of our mainstream unix product is in
serious danger because of the code changes, required for the Win32 port,
which affect the unix environment? If so, could those please discuss
their feelings with their spouses or shrinks unless they can actually
point at specific areas of the code?

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Katie Ward wrote:

The latest build is still: ftp://209.61.187.152/postgres/postgres_beta4.zip

This is not exactly what Jan submitted, and the catalog number is slightly
different, but it should do for testing.

That binary at least demonstrates, what could be built based on the code
submitted.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Tom Lane wrote:

Most variants of Unix are known to be pretty stable. Most variants of
Unix are known to follow the Unix standard semantics for sync() and
fsync(). I think we are entirely justified in doubting whether Windows
is a suitable platform for PG, and in wanting to run tests to find out.
Yes, we are holding Windows to a higher standard than we would for a
Unix variant.

Partly this is a matter of wanting to protect Postgres' reputation.
Just on sheer numbers, if there is a native Windows port then there are
likely to be huge numbers of people using Postgres on Windows. If
that's not going to be a reliable combination, we need to know it and
tell them so up-front. Otherwise, people will be blaming Postgres, not
Windows, when they lose data. It's an entirely different situation from
whether Postgres-on-Joe-Blow's-Unix-Variant loses data, first because of
visibility, and second because of the different user base. Am I being
paranoid to suspect that the average Postgres-on-Windows user will be
less clueful than the average Postgres-on-Unix user? I don't think so.

Assuming all your assumptions are right, why the hell is Oracle's and MS
SQL-Server's reputation that bloody good? And what about MySQL? They all
have a native Windows (sup)port for some time ... didn't harm their
reputation. I think that we got in bed with this ugly Cybill ... er ...
Cygwin thing had cost us more reputation than the sucking performance of
pre-7 releases all together.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

On Thu, 30 Jan 2003, Dave Page wrote:

On Wed, 29 Jan 2003, Ron Mayer wrote:

Cool irony in the automated .sig on the mailinglist software...
[...]
Sounds like you're basically saying is
_do_ 'kill -9' the postmaster...
and make sure it recovers gracefully...

...

It's not far off, but it's quite amusing none the less.

Sorry it looks like I should have added "50% :-), 50% :-|". I was
just amused by the irony of having the admonition against the
standard linux-low-memory condition. [ 90% :-) ]

More constructively, I think it'd be best for everyone if

a) postgresql does have a native windows port, and

b) it's positioned as a "well-tested beta" rather than "production
ready", with documentation saying what part people have
confidence in (the engine? operation in non-failure modes),
and what part is still in beta (OS failure modes).

IMHO this would have the advantages of

Even if it works better than many expect, it shows...

... that postgresql has a high standard even for beta releases,
where this community thinks about even broader system issues.

... corporations using it what aspects they need to focus on in
internal testing before using it in production environments.

... that we're interested in reaching a broader community.

... that postgresql is quite portable across platforms.

Note that I don't even care about running the windows version. I just think
that such a release can be positioned to _strengthen_ PostgreSQL's brand image
rather than weaken it.

Ron

Jan Wieck <JanWieck@Yahoo.com> writes:

Assuming all your assumptions are right, why the hell is Oracle's and MS
SQL-Server's reputation that bloody good?

They have marketing departments.

And what about MySQL?

What about it? Someone claimed in this thread that MySQL's Windows port
requires Cygwin. Is that true or not?

regards, tom lane

Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

And, by the way, who in their right mind tests a database server by repeated
yanking of the AC power?

Anybody who would like their data to survive a power outage.

... has UPS, ECC Ram on quality boards and storage subsystems that
guarantee the data to hit "some" surface after it passed the interface
... what's your point? Are you telling me that the reliability of an
EMC2 system depends on which OS it is receiving the bits from? Is SuSE
as reliable as TurboLinux? Or do I have to buy AIX to get the best
result?

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Hannu Krosing wrote:

I agree with Tom on yanking the plug while it's operating. Do you
know the difference between kill -9 and yanking the plug?

Kill -9 seems to me _less_ severe than yanking the plug but much easier
to automate, so that could be the first thing to test. You have no hope
of passing the pull-the-plug test if you can't survive even kill -9.

Perhaps we could have a special "reliability-regression" test that does
"kill -9 postmaster", repeatedly, at random intervals, and checks for
consistency ?

Maybe we will find even some options for some OS'es to "force-unmount"
disks. I guess that setting IDE disk's to read-only with hdparm could
possibly achieve something like that on Linux.

Get VMWare for Linux, run whatever OS you like in it and "kill -9" the
virtual machine. That's as close as you can get to "yanking" without
wearing out your power plugs.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Kevin Brown wrote:

Greg Copeland wrote:

On Thu, 2003-01-30 at 13:56, Dave Page wrote:

When properly configured, Windows can be reliable, maybe not as much as
Solaris or HPUX but certainly some releases of Linux (which I use as
well). You don't see Oracle or IBM avoiding Windows 'cos it isn't stable
enough.

I'm not jumping on one side or the other but I wanted to make clear on
something. The fact that IBM or Oracle use windows has absolutely zero
to do with reliability or stability. They are there because the market
is willing to spend money on their product. Let's face it, the share
holders of each respective company would come unglued if the largest
software audience in the world were completely ignored.

Simple fact is, your example really is pretty far off from supporting
any view. Bluntly stated, both are in that market because they want to
make money; they're even obligated to do so.

That's true, but it ignores the question that makes it relevant: has
their appearance in the Windows market tarnished their reputation?
More precisely, has it tarnished their reputation in the *Unix*
community? The answer, I think, is no.

And that *is* relevant to us, because our concern is about the
reputation of PostgreSQL, and what will happen to it if we release a
native Windows port to the world.

More to the point, does the unreliable Cygwin port possibly do our
reputation any good? It is known to crash with corruptions under less
than heavy load.

Looking at the arguments so far, nearly everyone who questions the Win32
port must be vehemently against the Cygwin stuff anyway. So that camp
should be happy to see it flushed down the toilet. And the pro-Win32
people want the native version because they are unhappy with the
stepchild-Cygwin stuff too, so they won't care too much.

Anyone here who likes the Cygwin port or can we yank it out right now?

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

What about it? Someone claimed in this thread that MySQL's Windows port
requires Cygwin. Is that true or not?

It's been a while, but I know I've installed MySQL on windows without any
separate step of installing Cygwin (I can't say 100% for sure that it didn't
install some part of Cygwin transparently to me).

Regards,
Jeff Davis

Jeff Davis wrote:

What about it? Someone claimed in this thread that MySQL's Windows port
requires Cygwin. Is that true or not?

It's been a while, but I know I've installed MySQL on windows without any
separate step of installing Cygwin (I can't say 100% for sure that it didn't
install some part of Cygwin transparently to me).

From the MySQL site's page about MySQL vs PostgreSQL:
http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html

"MySQL Server works better on Windows than PostgreSQL does. MySQL Server
runs as a native Windows application (a service on NT/2000/XP), while
PostgreSQL is run under the Cygwin emulation."

That seems pretty straightforward.

Regards and best wishes,

Justin Clift

Regards,
Jeff Davis

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Man, I go away for one day, and look what you guys get into. :-)

Let me shoot out some comments on this.

First, clearly the Win32 port is going to have more port-specific code
paths than any other port, so it is going to require extra testing even
if it wasn't our first non-Unix port. You can expect it to take some
extra effort even after the port has stabalized because when we add
something that works only on Unix, we will need to code some workaround
in Win32.

Second, there are going to be new error cases on this platform that we
can't anticipate, and some of that isn't going to show until we get it
released. Documenting those pitfalls, like only using NTFS, is a good
start.

Third, I suspect folks running Win32 aren't as particular about
stability/reliability, or they would have left MS products already.

Fourth, some say Win32 isn't an acceptable platform. It may or may not
be for specific people, but Linux may be an unacceptable platform for
some people too. I don't think we can second guess the users. We will
do our best and see how it goes.

Also, I have heard from several people that XP is the first OS MS got
right. That may or may not be true, but some feel things are getting
better. It is all a continuim with these OS's. Some are great, some
mediocre, some really bad, but people make decisions and choose bad ones
all the time. PostgreSQL just needs to be there, if only to migrate
them to a better platform later. If we aren't there, we can't show them
how good we are.

As for build environment, we have two audiences --- those using
binaries, and those compiling from source. Clearly we are going to have
more binary users vs. source users on Win32 than on any other platform,
so at this stage I think making thing easier for the majority of our
Unix developers is the priority, meaning we should use our existing
Makefiles and cygwin to compile. Later, if things warrant it, we can do
VC++ project files somehow.

Lastly, SRA just released _today_ their first Win32 port of PostgreSQL,
and it is _threaded_:

http://osb.sra.co.jp/PowerGres/

Now, that's a port!

Also, when I am back home for an extended period starting in March, I
will going through Jan's patch (if no one does it first) and
submit/apply it in pieces that address specific Win32 issues, like path
names or carriage returns. Once those are in, we can look at the more
complex issues of build handling.

So, as far as I am concerned, we will have a Win32 port in 7.4. It will
not be perfect, but it will be as good as we can do. We are also
getting point-in-time recovery in 7.4, so that may help us with Win32
port failures too.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Friday 31 January 2003 05:08, Tom Lane wrote:

Jan Wieck <JanWieck@Yahoo.com> writes:

And what about MySQL?

What about it? Someone claimed in this thread that MySQL's Windows port
requires Cygwin. Is that true or not?

For reference, from the INSTALL-SOURCE file included in
the MySQL sources which I have lying about [*]:

[*] danged legacy applications ;-)

--QUOTE START--

Windows Source Distribution
---------------------------

You will need the following:

* VC++ 6.0 compiler (updated with 4 or 5 SP and Pre-processor
package) The Pre-processor package is necessary for the macro
assembler. More details at:
`http://msdn.microsoft.com/vstudio/sp/vs6sp5/faq.asp&#39;.

* The MySQL source distribution for Windows, which can be downloaded
from `http://www.mysql.com/downloads/&#39;.

Building MySQL

1. Create a work directory (e.g., workdir).

2. Unpack the source distribution in the aforementioned directory.

3. Start the VC++ 6.0 compiler.

4. In the `File' menu, select `Open Workspace'.

5. Open the `mysql.dsw' workspace you find on the work directory.

6. From the `Build' menu, select the `Set Active Configuration' menu.

7. Click over the screen selecting `mysqld - Win32 Debug' and click
OK.

8. Press `F7' to begin the build of the debug server, libs, and some
client applications.

9. When the compilation finishes, copy the libs and the executables
to a separate directory.

10. Compile the release versions that you want, in the same way.

11. Create the directory for the MySQL stuff: e.g., `c:\mysql'

12. From the workdir directory copy for the c:\mysql directory the
following directories:

* Data

* Docs

* Share

13. Create the directory `c:\mysql\bin' and copy all the servers and
clients that you compiled previously.

14. If you want, also create the `lib' directory and copy the libs
that you compiled previously.

15. Do a clean using Visual Studio.

Set up and start the server in the same way as for the binary Windows
distribution. *Note Windows prepare environment::.

--QUOTE END--

Ian Barwick
barwick@gmx.net

-----Original Message-----
From: Greg Copeland [mailto:greg@copelandconsulting.net]
Sent: 30 January 2003 22:47
To: Dave Page
Cc: Tom Lane; PostgresSQL Hackers Mailing List
Subject: Re: [mail] Re: [HACKERS] Windows Build System

I have lost entire directory trees (and all associated data)
on NTFS before. NTFS was kind enough to detect an
inconsistency during boot and repaired the file system by
simply removing any and all references to the top level
damaged directory (on down). Sure, the file system was in a
known good state following the repair but the 2-days to
recover from it, pretty much stunk!

Don't get me wrong, I'm not saying it doesn't go toes up, just that in
my experience (going back the NT3.1) it's not a daily occurance.

You also compared NTFS with ext2. That's not exactly fair.
Better you should compare NTFS with ext3, XFS, JFS, ReiserFS.
It's a better, more fair comparison, as now we're talking
about the same category of file system.

I realise the differences, but I don't currently use ext3, xfs, jfs or
reiserfs on any of my production boxes so can't make any observations
about them. I did, less than a month ago, lose and entire pg data
directory on an ext2 partition though :-(

Regards, Dave.

-----Original Message-----
From: Jeff Davis [mailto:jdavis-pgsql@empires.org]
Sent: 31 January 2003 06:27
To: pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

What about it? Someone claimed in this thread that MySQL's Windows
port requires Cygwin. Is that true or not?

It's been a while, but I know I've installed MySQL on windows
without any
separate step of installing Cygwin (I can't say 100% for sure
that it didn't
install some part of Cygwin transparently to me).

Last time I installed it ~6 months ago for some testing, it did install
cygwin1.dll which is basically Cygwin.

Regards, Dave.

-----Original Message-----
From: Dave Page
Sent: 30 January 2003 19:57
To: Vince Vielhaber; Lamar Owen
Cc: pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Windows Build System

I ought to plonk you for a comment like that. Especially
coming from the person who's crap I've been trying to sort
out for the last couple of months.

Apologies for that folks. Momentary lack of good judgement on my part.

Regards, Dave.

On Thu, 2003-01-30 at 15:56, Tom Lane wrote:

The reason the TIP is
still there is that there are platforms on which that stuff doesn't work
very nicely. It's better to let the postmaster exit cleanly so that
that state gets cleaned up. I have no idea what the comparable issues
are for a native Windows port, but I bet there are some...

That's why I proposed an automated test for this too. It is mostly
important when conquering new OS'es, but could also be nice to have when
testing if changes to storage manager or some other important subsystem
will break anything.

regards, tom lane

--
Hannu Krosing <hannu@tm.ee>

On Thu, 2003-01-30 at 20:29, Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

While I understand (and agree with) your (and Vince's) reasoning on why
Windows should be considered less reliable, neither of you have provided a
sound technical basis for why we should not hold the other ports to the same
standards.

The point here is that Windows is virgin territory for us. We know
about Unix. When we port to a new Unix variant, we are dealing with the
same system APIs, and in many cases large chunks of the same system
code, that we've dealt with before. It's reasonable for us to have
confidence that Postgres will work the same on such a platform as it
does on other Unix variants. And the track record of reliability that
we have built up across a bunch of Unix variants gives us
cross-pollinating confidence in all of them.

Windows shares none of that heritage. It is the first truly new port,
onto a system without any Unix background, that we have ever done AFAIK.

I don't know how much Unix backgroun BeOS has. It does have a better
POSIX support than Win32, but I don't know how much of it is really from
Unix.

Claiming that it doesn't require an increased level of testing is
somewhere between ridiculous and irresponsible.

We should have at least _some_ platforms (besides Win32) that we could
clain to have run thorough test on.

I suspect that RedHat does some (perhaps even severe) testing for
RHAS/RHDB, but I don't know of any other thorough testing.

Or should reliability testing actually be something left for commercial
entities ?

I believe we should test every release as pathologically as Vince
has stated for Win32.

Great, go to it. That does not alter the fact that today, with our
existing port history, Windows has to be treated with extra suspicion.

I don't think that the pull-the-plug scenario happens enough in the wild
that even our seven-year track record can prove anything conlusive about
the reliability. I have not found instructions about providing that kind
of reliability in the docs either - things like what filesystems to use
on what OSes and with which mount options.

We just mention -f as a way to get non-reliable system ;)

I do not buy the argument you are making that we should treat all
platforms alike. If we had a ten-year-old Windows port, we could
consider it as stable as all our other ten-year-old Unix ports.
We don't. Given that we don't have infinite resources for testing,
it's simple rationality to put more testing emphasis on the places
that we suspect there will be problems. And if you don't suspect
there will be problems on Windows, you are being way too naive :-(

"We" don't have that old windows port, but I guess that there are native
windows ports at least a few years old.

Do we want to encourage Win32? (some obviously do, but I don't) Well, telling
people that we have tested PostgreSQL on Win32 much more thoroughly than on
Unix is in a way telling them that we think it is _better_ than the
time-tested Unix ports ('It passed a harder test on Win32. Are we afraid the
Unix ports won't pass those same tests?').

If it passes the tests, good for it. I honestly do not expect that it
will. My take on this is that we want to be able to document the
problems in advance, rather than be blindsided.

Where can I read such documentations for *nix ports ?

What I have read in this list is that losing different voltages in wrong
order can just write over any sectors on a disk, and that power-cycling
can blow up computers. I don't expect even Unix to survive that!

--
Hannu Krosing <hannu@tm.ee>

Jan Wieck <JanWieck@Yahoo.com> writes:

Assuming all your assumptions are right, why the hell is Oracle's and MS
SQL-Server's reputation that bloody good?

They have marketing departments.

... As well as sizable systems integration departments devoted to the
platforms in question. PostgreSQL doesn't have the latter, although the
recent efforts make a move towards it.

And what about MySQL?

What about it? Someone claimed in this thread that MySQL's Windows port
requires Cygwin. Is that true or not?

http://www.mysql.com/downloads/mysql-3.23.html
"Windows downloads

The Windows binaries use the Cygwin library. Source code for the version of
Cygwin we have used is available on this page."
http://www.mysql.com/downloads/cygwin.html
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/spiritual.html
"When you have eliminated the impossible, whatever remains, however
improbable, must be the truth." -- Sir Arthur Conan Doyle (1859-1930),
English author. Sherlock Holmes, in The Sign of Four, ch. 6 (1889).
[...but see the Holmesian Fallacy, due to Bob Frankston...
<http://www.frankston.com/public/Essays/Holmesian%20Fallacy.asp&gt;]

Jan Wieck wrote:

Looking at the arguments so far, nearly everyone who questions the Win32
port must be vehemently against the Cygwin stuff anyway. So that camp
should be happy to see it flushed down the toilet. And the pro-Win32
people want the native version because they are unhappy with the
stepchild-Cygwin stuff too, so they won't care too much.

What is interesting is that the MySQL folk don't seem to be vehemently against
it, as a look at their downloads pages indicate that they depend on Cygwin for
the Windows port of their product.
--
output = ("cbbrowne" "@ntlug.org")
http://www.ntlug.org/~cbbrowne/lisp.html
"What did we agree about a leader??"
"We agreed we wouldn't have one."
"Good. Now shut up and do as I say..."

Jeff Davis wrote:

What about it? Someone claimed in this thread that MySQL's Windows port
requires Cygwin. Is that true or not?

It's been a while, but I know I've installed MySQL on windows without any
separate step of installing Cygwin (I can't say 100% for sure that it didn't
install some part of Cygwin transparently to me).

That may have involved "not being sufficiently observant," because the company
quite clearly documents Cygwin as a dependancy.
http://www.mysql.com/downloads/cygwin.html
--
output = ("aa454" "@freenet.carleton.ca")
http://www3.sympatico.ca/cbbrowne/linuxxian.html
Change is inevitable, except from a vending machine.

Jeff Davis wrote:

What about it? Someone claimed in this thread that MySQL's Windows port
requires Cygwin. Is that true or not?

It's been a while, but I know I've installed MySQL on windows without any
separate step of installing Cygwin (I can't say 100% for sure that it didn'

t

install some part of Cygwin transparently to me).

From the MySQL site's page about MySQL vs PostgreSQL:
http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html

"MySQL Server works better on Windows than PostgreSQL does. MySQL Server
runs as a native Windows application (a service on NT/2000/XP), while
PostgreSQL is run under the Cygwin emulation."

That seems pretty straightforward.

But it's not /nearly/ that straightforward.

If you look at the downloads that MySQL AB provides, they point you to a link
that says "Windows binaries use the Cygwin library."

Which apparently means that this "feature" is not actually a feature. Unlike
PostgreSQL, which "is run under the Cygwin emulation," MySQL runs as a native
Windows application (with Cygwin emulation). Apparently those are not at all
the same thing, even though they are both using Cygwin...
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne&gt; rate me
http://cbbrowne.com/info/linuxdistributions.html
(1) Sigs are preceded by the "sigdashes" line, ie "\n-- \n" (dash-dash-space).
(2) Sigs contain at least the name and address of the sender in the first line.
(3) Sigs are at most four lines and at most eighty characters per line.

Christopher Browne wrote:
<snip>

From the MySQL site's page about MySQL vs PostgreSQL:
http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html

"MySQL Server works better on Windows than PostgreSQL does. MySQL Server
runs as a native Windows application (a service on NT/2000/XP), while
PostgreSQL is run under the Cygwin emulation."

That seems pretty straightforward.

But it's not /nearly/ that straightforward.

If you look at the downloads that MySQL AB provides, they point you to a link
that says "Windows binaries use the Cygwin library."

Which apparently means that this "feature" is not actually a feature. Unlike
PostgreSQL, which "is run under the Cygwin emulation," MySQL runs as a native
Windows application (with Cygwin emulation). Apparently those are not at all
the same thing, even though they are both using Cygwin...

Hmm... wonder if they're meaning that MySQL compiles and executes as a
True native windows application (skipping any unix compatibility calls),
and it's just some of the support utils that use cygwin, or if they're
trying to say that PostgreSQL has to operate entirely in the cygwin
environment, whereas they don't?

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

On Thu, 2003-01-30 at 16:01, Vince Vielhaber wrote:

Dave, Lamar and Katie can cheer now 'cuze this is the last comment
I'm going to make on this. All others will be ignored, probably.

The one thing I haven't seen from Dave, Lamar or Katie on this is
reputation. You're all for the PostgreSQL name going on it but I
have yet to see any of you so sure of yourselves that you'd put
your own name on it. The license allows it. Red Hat did it. I
see no "PageSQL" or "KatieSQL" or even an "Oh-Win SQL" being offered
up. Yet all three of you are advocating that the PostgreSQL stamp
of approval should be immediately placed on it (ok, Lamar may not
be as in favor as the Dave and Katie).

Oh-win SQL! Man that was great :-) If only all of your posts were so
witty...

Without documented testing and sufficient warnings until enough
history is banked, I don't think a native windows port should be
given any kind of seal of approval. After that, what about keeping
the code current? In a year or so will it suffer from bit-rot and
be the source of complaints? Are there going to be security concerns
surrounding it? Is there going to be a bunch of scrambling going on
to put out a patch when the latest active-x bug hoses the data dir?

We already support postgresql on cygwin, and we know that's crap. Having
a native emulation can only improve that situation, so I don't see any
reason not to move in that direction. All of this "stamp of approval"
talk is really pointless at this juncture; no matter how much testing
has been done, none of it means a lick until the code is integrated into
the 7.4 branch. In the mean time, if some of the unix oriented guys want
to devise a suggested test plan that can be used to determine if we are
going to call the native windows support "production grade" or merely a
vast improvement over the cygwin developers version, well I bet the
windows folks would appreciate that. Even more so if someone runs those
tests against a linux box so that we have actual statistics to compare
against.

Robert Treat

On Fri, 2003-01-31 at 07:22, Christopher Browne wrote:

But it's not /nearly/ that straightforward.

If you look at the downloads that MySQL AB provides, they point you to a link
that says "Windows binaries use the Cygwin library."

Which apparently means that this "feature" is not actually a feature. Unlike
PostgreSQL, which "is run under the Cygwin emulation," MySQL runs as a native
Windows application (with Cygwin emulation). Apparently those are not at all
the same thing, even though they are both using Cygwin...

I'm confused as to whether you are being sarcastic or truly seem to
think there is a distinction here. Simple question, does MySQL require
the cygwin dll's (or statically linked to) to run?

If the answer is yes, then there is little question that they are as
"emulated" as is the current PostgreSQL/Win32 effort.

Care to expand on exactly what you believe the distinction is? ...or
did I miss the humor boat? :(

Regards,

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

----- Original Message -----
From: "Greg Copeland" <greg@CopelandConsulting.Net>

I'm confused as to whether you are being sarcastic or truly seem to
think there is a distinction here. Simple question, does MySQL require
the cygwin dll's (or statically linked to) to run?

If the answer is yes, then there is little question that they are as
"emulated" as is the current PostgreSQL/Win32 effort.

Care to expand on exactly what you believe the distinction is? ...or
did I miss the humor boat? :(

I just installed it (their latest gama), to see what was there (and
uninstalled it straight away ;-). There was a cygwinb19.dll (I think that's
what it was called) installed.

In any case, if we are talking about "industrial strength", is this the
comparison we should be using? ;-)

andrew

Christopher Browne wrote:

<snip>

From the MySQL site's page about MySQL vs PostgreSQL:
http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html

"MySQL Server works better on Windows than PostgreSQL does. MySQL
Server runs as a native Windows application (a service on
NT/2000/XP), while PostgreSQL is run under the Cygwin emulation."

That seems pretty straightforward.

But it's not /nearly/ that straightforward.

If you look at the downloads that MySQL AB provides, they

point you to a link that says "Windows binaries use the Cygwin

library."

Which apparently means that this "feature" is not actually

a feature.

Unlike
PostgreSQL, which "is run under the Cygwin emulation,"

MySQL runs as a native

Windows application (with Cygwin emulation). Apparently

those are not at all

the same thing, even though they are both using Cygwin...

Justin Clift replied:

Hmm... wonder if they're meaning that MySQL compiles and
executes as a True native windows application (skipping any unix
compatibility calls), and it's just some of the support utils that
use cygwin, or if they're trying to say that PostgreSQL has to
operate entirely in the cygwin environment, whereas they don't?

I just downloaded the latest productin source (3.3.55) and it appears to
me that:

1) It uses Cygwin emulation via a dll.

2) It uses Visual Studio C++ 6.0 for the primary build environment. It
compiles out of the box without having to learn Unix-style build
systems, config, make, etc. No warnings, no errors, it just builds out
of the box. If I did not have a lot of experience building databases I
certainly would have found their support for Windows compelling. This is
a big reason why they are #1.