Thread

Re: [mail] Re: Windows Build System

Dave Page <dpage@vale-housing.co.uk> — 2003-01-30T13:08:58Z

> -----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.

Re: [mail] Re: Windows Build System

Vince Vielhaber <vev@michvhf.com> — 2003-01-30T13:24:50Z

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.

Re: [mail] Re: Windows Build System

Hannu Krosing <hannu@tm.ee> — 2003-01-30T15:44:19Z

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>

Re: [mail] Re: Windows Build System

Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-30T15:56:24Z

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

Re: [mail] Re: Windows Build System

Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-30T16:12:10Z

"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

Re: [mail] Re: Windows Build System

Lamar Owen <lamar.owen@wgcr.org> — 2003-01-30T18:03:00Z

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

Re: [mail] Re: Windows Build System

Joerg Hessdoerfer <joerg.hessdoerfer@sea-gmbh.com> — 2003-01-30T18:11:04Z

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

Re: [mail] Re: Windows Build System

Vince Vielhaber <vev@michvhf.com> — 2003-01-30T18:17:34Z

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.

Re: [mail] Re: Windows Build System

Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-30T18:34:32Z

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

Re: [mail] Re: Windows Build System

Lamar Owen <lamar.owen@wgcr.org> — 2003-01-30T18:41:50Z

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

Re: [mail] Re: Windows Build System

Vince Vielhaber <vev@michvhf.com> — 2003-01-30T19:20:26Z

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.

Re: [mail] Re: Windows Build System

Lamar Owen <lamar.owen@wgcr.org> — 2003-01-30T19:48:50Z

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

Re: [mail] Re: Windows Build System

Andrew Dunstan <andrew@dunslane.net> — 2003-01-30T19:55:02Z

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

Re: [mail] Re: Windows Build System

Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-30T20:29:50Z

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

Re: Windows Build System - My final thoughts

Vince Vielhaber <vev@michvhf.com> — 2003-01-30T21:01:22Z

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.

Re: Windows Build System - My final thoughts

Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-30T21:12:21Z

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

Re: [mail] Re: Windows Build System

Lamar Owen <lamar.owen@wgcr.org> — 2003-01-30T21:29:15Z

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

Re: Windows Build System - My final thoughts

Lamar Owen <lamar.owen@wgcr.org> — 2003-01-30T21:42:11Z

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

Re: [mail] Re: Windows Build System

Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-30T21:54:39Z

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

Re: [mail] Re: Windows Build System

Lamar Owen <lamar.owen@wgcr.org> — 2003-01-30T22:30:54Z

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

Re: [mail] Re: Windows Build System

Kevin Brown <kevin@sysexperts.com> — 2003-01-30T22:39:59Z

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

Re: [mail] Re: Windows Build System

Kurt Roeckx <q@ping.be> — 2003-01-30T23:09:05Z

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

Re: [mail] Re: Windows Build System

Kevin Brown <kevin@sysexperts.com> — 2003-01-30T23:16:36Z

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

Re: [mail] Re: Windows Build System

Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-30T23:39:51Z

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

Re: [mail] Re: Windows Build System

Lamar Owen <lamar.owen@wgcr.org> — 2003-01-30T23:57:27Z

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

Re: [mail] Re: Windows Build System

Jan Wieck <janwieck@yahoo.com> — 2003-01-31T03:06:36Z

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 #

Re: [mail] Re: Windows Build System

Ron Mayer <ron@intervideo.com> — 2003-01-31T03:20:15Z

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

Re: [mail] Re: Windows Build System

Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-31T04:08:41Z

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

Re: [mail] Re: Windows Build System

Jan Wieck <janwieck@yahoo.com> — 2003-01-31T04:37:17Z

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 #

Re: [mail] Re: Windows Build System

Jan Wieck <janwieck@yahoo.com> — 2003-01-31T04:54:17Z

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 #

Re: [mail] Re: Windows Build System

Jeff Davis <jdavis-pgsql@empires.org> — 2003-01-31T06:27:15Z

> 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

Re: [mail] Re: Windows Build System

Justin Clift <justin@postgresql.org> — 2003-01-31T07:49:23Z

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

Re: Windows Build System - My final thoughts

Bruce Momjian <pgman@candle.pha.pa.us> — 2003-01-31T08:21:19Z

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

Re: [mail] Re: Windows Build System

Ian Barwick <barwick@gmx.net> — 2003-01-31T08:55:09Z

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'.

   * The MySQL source distribution for Windows, which can be downloaded
     from `http://www.mysql.com/downloads/'.

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

Re: [mail] Re: Windows Build System

Hannu Krosing <hannu@tm.ee> — 2003-01-31T11:42:58Z

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>

Re: [mail] Re: Windows Build System

Hannu Krosing <hannu@tm.ee> — 2003-01-31T12:44:32Z

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>

Re: [mail] Re: Windows Build System

Your Name <cbbrowne@cbbrowne.com> — 2003-01-31T13:12:14Z

> 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>]

Re: [mail] Re: Windows Build System

Your Name <cbbrowne@cbbrowne.com> — 2003-01-31T13:16:24Z

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.

Re: [mail] Re: Windows Build System

Your Name <cbbrowne@cbbrowne.com> — 2003-01-31T13:22:47Z

> 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> 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.

Re: [mail] Re: Windows Build System

Justin Clift <justin@postgresql.org> — 2003-01-31T13:52:00Z

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

Re: Windows Build System - My final thoughts

Robert Treat <xzilla@users.sourceforge.net> — 2003-01-31T14:48:25Z

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

Re: [mail] Re: Windows Build System

Greg Copeland <greg@copelandconsulting.net> — 2003-01-31T18:20:00Z

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

Re: [mail] Re: Windows Build System

Andrew Dunstan <andrew@dunslane.net> — 2003-01-31T19:08:04Z

----- 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

Re: [mail] Re: Windows Build System

Curtis Faith <curtis@galtcapital.com> — 2003-01-31T19:18:29Z

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.

3) The statement by the MySQL folks above that MySQL runs as a native
Windows application (a service on NT/2000/XP) is indicative of why MySQL
is kicking PostgreSQL's butt in terms of popularity. It is "marketing
speak" at its best. It is technically true, MySQL runs as a service. As
Christopher Browne points out, they still use the Cygwin Emulation
layer. The statement is misleading, however, as it implies that they
don't use any emulation but they do.

The salient points:

   a) Running as a service is important as this the way NT/2000
administrators manage server tasks. The fact that PostgreSQL's Cygwin
emulation doesn't do this is very indicative of inferior Windows
support.

   b) MySQL recognizes that the important issue is to appear to be a
well supported Windows application rather than to actually be one.

   c) It is probably much easier to add the support for running as an NT
service than it is to write a true native port with no Cygwin
dependency. NT Service support is basically a single funtion wrapper for
certain API calls (startup, shutdown, etc.) that enable the Windows
administration tools to deal with all servers in a similar manner. 

They have worked on that which makes them look better, makes their
prospective customers happier, and makes it easier to support. Exactly
what any good product development organization that listens to their
customers would have done.

<flame on>
IMHO, PostgreSQL will never have the same level of use in the field as
MySQL currently does as long as there is the kind "head in the sand"
attitude about Windows that I've seen here on the hackers list,
especially as evidenced by the recent outright attacks against those who
are simply trying to port PostgreSQL to the largest platform out there
today.

There have been some very legitimate points about Windows being a new
platform, one that will likely see a lot of users, and therefore one
that should be more thoroughly tested before release than the typical
port to another flavor of *nix. 

However, the way the conversation started reminds me of some of the chat
discussions I've seen between young teens.

I was a Mac developer way, way back and long ago realized that the best
often loses and that better marketing beats better engineering every
single time.
<\flame off>

DISCLAIMER: I hate Microsoft and Windows drives me nuts.

- Curtis

Re: [mail] Re: Windows Build System

Your Name <cbbrowne@cbbrowne.com> — 2003-01-31T22:07:34Z

> 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?

I don't know if there's a distinction; read in whatever sarcasm is
deserved by the reality of things.

> If the answer is yes, then there is little question that they are as
> "emulated" as is the current PostgreSQL/Win32 effort.

Just so.  If the answer is yes, then the MySQL folk are claiming an
advantage that has no reality to it, in effect, "We aren't using Cygwin
emulation, so we're better...  (Whoops, we're actually /using/ Cygwin
emulation.)

> Care to expand on exactly what you believe the distinction is?  ...or
> did I miss the humor boat?  :(

I'm making the generous assumption that since /they/ claim that there is
some distinction, that there perhaps is one.
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://cbbrowne.com/info/oses.html
"All language designers are arrogant.  Goes with the territory..."  
-- Larry Wall

Re: Windows Build System - My final thoughts

Lamar Owen <lamar.owen@wgcr.org> — 2003-02-01T00:26:27Z

On Friday 31 January 2003 03:21, Bruce Momjian wrote:
> Man, I go away for one day, and look what you guys get into.  :-)

No duh.  Whew.

> Lastly, SRA just released _today_ their first Win32 port of PostgreSQL,
> and it is _threaded_:

> 	http://osb.sra.co.jp/PowerGres/

Is there an English translation of the site so one who doesn't speak or write 
Japanese can try it out?
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: [mail] Re: Windows Build System

Peter Eisentraut <peter_e@gmx.net> — 2003-02-01T01:06:48Z

Curtis Faith writes:

>    a) Running as a service is important as this the way NT/2000
> administrators manage server tasks. The fact that PostgreSQL's Cygwin
> emulation doesn't do this is very indicative of inferior Windows
> support.

No, it is indicative of the inability to read the documentation.
PostgreSQL on Cygwin runs as a service if and only if you ask it to.

-- 
Peter Eisentraut   peter_e@gmx.net

Re: Windows Build System - My final thoughts

Jeff Davis <jdavis-pgsql@empires.org> — 2003-02-01T01:35:54Z

> 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.

I'm ignorant when it comes to build environments on windows, but I was under 
the impression that DJGPP was mostly a complete environment. Are there any 
plans to support it, or is it even possible?

> 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.

Interesting consolation :)

Regards,
	Jeff Davis

Re: Windows Build System - My final thoughts

Justin Clift <justin@postgresql.org> — 2003-02-01T05:08:31Z

Bruce Momjian wrote:
<snip>
> 
> 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.

If anyone's interested, the "PostgreSQL 7.3.1 Proof of Concept for 
Windows Alpha 1" (yes the warnings are even built into the name) 
easy-installer that I whipped up using Inno Setup was quietly uploaded 
to the pgsql project on Sourceforge the other night.  It's using 
PostgreSQL + cygwin, pretty much stock standard but pre-installed and 
wrapped up into a single installable.

As an indicater, having made no release annoucement, and only having put 
a one paragraph small mention with a link to it on the Techdocs 
"Installing On Windows" page (with warnings), over 1,600 people 
downloaded it in the first 24 hours (that's about 17.1 GB of bandwidth).

This was just a version so that I could practise some windows packaging 
and see what kind of things we'd need to address.  Dave has already 
pointed out that we're probably going to need to do this so it can be 
made into a "Merge Module" and other things.

A couple of bits of interest turned up whilst packaging:

  + There are unix command line tools that PostgreSQL relies on.  For 
example, when running initdb, it errors out if some tools aren't 
present.  i.e. sed, grep, ash (cygwin's "/bin/sh"), and from memory a 
few others

  + GPL licensing issues.  Am trying to get my head around the 
implications - with regards to licensing - if we released a proper 
version with some of the cygwin tools included... i.e. grep, sed, etc. 
Don't think that places could use it embedded with their products and 
not at least have source available, but still haven't totally grokked 
this all completely yet.  Not going to commit any code to the GBorg 
project that was setup the other day until this is sorted out. 
PostgreSQL 7.4 on Win32 should be properly BSD too.

  + Aside from all this, it might be nice to have a few Win32 specific 
gui pieces in place at the time that PostgreSQL 7.4 Win32 is released. 
Am sure they'll develop over time, but was thinking we should at least 
make a good impression with the first release.  Hey, if we make a really 
bad impression with the first release, then there might not be the 
quadruple-zillion Windows PG users after all.  If that sounds like a 
good idea, maybe adding the GUC variables "random_query_delay" 
(minutes), "crash_how_often" (seconds), and "reboot_plus_corrupt_please" 
(true/false)?

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

Re: [mail] Re: Windows Build System

Curt Sampson <cjs@cynic.net> — 2003-02-01T06:06:29Z

On Sat, 1 Feb 2003, Peter Eisentraut wrote:

> Curtis Faith writes:
>
> >    a) Running as a service is important as this the way NT/2000
> > administrators manage server tasks. The fact that PostgreSQL's Cygwin
> > emulation doesn't do this is very indicative of inferior Windows
> > support.
>
> No, it is indicative of the inability to read the documentation.
> PostgreSQL on Cygwin runs as a service if and only if you ask it to.

I would say that not supporting those who have an inability to read
documentation would count as "inferior Windows support." :-)

What I'm hearing here is that all we really need to do to "compete" with
MySQL on Windows is to make the UI a bit slicker. So what's the problem
with someone building, for each release, a set of appropriate binaries, and
someone making a slick install program that will install postgres,
install parts of cygwin if necessary, and set up postgres as a service?

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

Re: [mail] Re: Windows Build System

Greg Copeland <greg@copelandconsulting.net> — 2003-02-01T06:33:58Z

On Fri, 2003-01-31 at 16:07, Christopher Browne wrote:

> I'm making the generous assumption that since /they/ claim that there is
> some distinction, that there perhaps is one.

I've used the cygwin environment enough to know that there isn't any. 
If it's linked against the cygwin dll, the application runs in an
"emulated unix environment."  To say it's emulated is really too strong
but to say it adds *tons* of overhead certainly won't make you a lair. 
;)

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

Re: Windows Build System - My final thoughts

Ian Barwick <barwick@gmx.net> — 2003-02-01T10:08:53Z

On Saturday 01 February 2003 01:26, Lamar Owen wrote:
> On Friday 31 January 2003 03:21, Bruce Momjian wrote:
> > Man, I go away for one day, and look what you guys get into.  :-)
>
> No duh.  Whew.
>
> > Lastly, SRA just released _today_ their first Win32 port of PostgreSQL,
> > and it is _threaded_:
> >
> > 	http://osb.sra.co.jp/PowerGres/
>
> Is there an English translation of the site so one who doesn't speak or
> write Japanese can try it out?

Can't see one, but here is a summarized translation of the relevant
parts as I understand them.

HTH

Ian Barwick
barwick@gmx.net


http://osb.sra.co.jp/PowerGres/
-------------------------------

"Announcement about Powergres"

* Release of [ Beta download ] of PowerGres (31.1.2003)
* [Press release] (27.11.2002)


http://osb.sra.co.jp/PowerGres/introduction.php
-----------------------------------------------

"PowerGres (PostgreSQL on Windows)"
"The standard open source database 'PostgreSQL' on Windows"

PowerGres is a DBMS which has been developed on the basis
of PostgreSQL and ported to Windows (2000 / XP).

PowerGres' features:
  Port of Postgres to Windows
     The popular Unix/Linux OS Database "postgresql"
     becomes more accessible

  Optimised for the Windows environment
     A thread model enabling effective processing of
     multiple transactions is used. This enables
     maximum performance in a windows environment.

  Web back end DB at low cost
     There is no limit to the number of users who
     can connect concurrently, making (PowerGres)
     suitable as a low cost web app backend DB

  GUI admin tool
     A GUI admin tool is packaged with powergres. This
     enables beginners to perform database management 
     visually / per point and click
  
  Japanese manual provided
     (translation of original Postgres manuals)

  C, Java Interface spport
      API for C and Java provided

  (pretty pictures, presumably of GUI admin tool)


http://osb.sra.co.jp/PowerGres/function.php
===========================================

"Table of PowerGres functions"

(comparision with "other DBs for windows", 
seems a bit pointless, left out)


http://osb.sra.co.jp/PowerGres/catalog.php
==========================================

"Product catalogue"
(more: overview)

Environment:
  CPU: Pentiium or compat, min 300Mhz
  OS: Windows 2000 (SP2 or later), XP
  Memory: 128MB (rec: 256MB +)
  Drive space: 100MB+

Product:
   - 1 CD ROM
   - PowerGres installer
   - PowerGres
   . PowerGres GUI admin tol
   - PostgreSQL 7.3 Japanese documentation
   - also:
      - PowerGres handbook
      - user registration
      - misc

Installation support
   Free support by email and fax for 30 days after registration

Price
   48,000 Yen + tax  (probably 5% sales tax; we're talking roughly
                      total US$ 500 or about the same in Euros)
   Available from March 2003 (scheduled)
   Beta download available from Jan 2003


http://powergres.sra.co.jp/
===========================

(Beta dowload)

Thankyou for your interest in PowerGres.
A free beta version of PowerGres is available.
Currently 1.0b s available for download.
It can be evaluated for 30 days. Please
do not hesitate to try before you buy.
We cannot offer any support for this software.
Use at own risk (blah blah). Also , be aware
the Beta version has some restrictions /
lack of features compared to the release version, see
here:
  http://osb.sra.co.jp/PowerGres/beta_restriction.php

(list of things, mainly command line tools with certain
 options not working properly)

DOWNLOAD FORM:

Name*
Email*
Company
Dept.
Postal code*
Address*

* required. (Note: Japanese postal code are like 111-2222 ).

( There follows a select box clicked by default enabling
SRA to send you emails...  The button is "Send".)

(following that, privacy info boilerplate).



http://osb.sra.co.jp/PowerGres/faq.php
======================================

(not a complete translation, only the interesting points 
from this page)

"FAQ"


- License: one license per server; client software
  is unrestricted ,though no free support available.
- it is possible to transfer data from a PostgreSQL 
  installation to PowerGres, though some
  restrictions apply;
- restrictions are among others:
   - max simultaneous connections 50 users
     (seems to contradict a previous statement...)
   - User-definable functions only in C, SQL, PL/pgSQL
   - No UNIX domain socket support
   - authentication only trust/reject/md5

Re: [mail] Re: Windows Build System

Justin Clift <justin@postgresql.org> — 2003-02-02T03:42:49Z

Curt Sampson wrote:
<snip>
 > What I'm hearing here is that all we really need to do to "compete" with
 > MySQL on Windows is to make the UI a bit slicker. So what's the problem
 > with someone building, for each release, a set of appropriate 
binaries, and
 > someone making a slick install program that will install postgres,
 > install parts of cygwin if necessary, and set up postgres as a service?

The non-code related parts of the Win32 port of PostgreSQL that are 
being looked at:

  + Working on the packaging bits (slick install program) already.  Have 
created a project - pgsqlwin - on GBorg to hold any specific bits we need.

    http://gborg.postgresql.org/project/pgsqlwin/projdisplay.php

   First release of the *extremely alpha* "Proof of Concept" version is at:

    http://prdownloads.sourceforge.net/pgsql/PgSQL731wina1.exe?download


  + Concerned about including GPL stuff without having 100% totally 
investigated the ramifications for people including the Win32 version of 
PostgreSQL as a built-in part of their applications.  Not going to 
commit anything even slightly GPL related to that GBorg project until it 
100% safe to do so without affect our ability to release it as BSD. 
Have some preliminary information regarding this, but just need to wrap 
my head around it properly.  Not going to look at it closely for another 
week or so.

  + It would be greatly helpful to have some way for the install program 
to automatically add the "Log in as a service" Win32 priviledge to the 
"postgres" user without having to instruct the user to do so.  We can 
create the user automatically through a shell command, but no idea how 
to add that permission.  If someone could do some Win32 API stuff to do 
it behind the scenes without a shell command even, that would be great.

  + The WinMaster project is a first go at creating a Win32 GUI command 
console for controlling the PostgreSQL service.  It's still a bit too 
basic for real use though:

    http://gborg.postgresql.org/project/winmaster/projdisplay.php

Further suggestions, volunteers, etc are totally welcome.

:-)

Regards and best wishes,

Justin Clift


 > cjs


-- 
"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

Re: Windows Build System - My final thoughts

Bruce Momjian <pgman@candle.pha.pa.us> — 2003-02-02T12:17:17Z

Lamar Owen wrote:
> On Friday 31 January 2003 03:21, Bruce Momjian wrote:
> > Man, I go away for one day, and look what you guys get into.  :-)
> 
> No duh.  Whew.
> 
> > Lastly, SRA just released _today_ their first Win32 port of PostgreSQL,
> > and it is _threaded_:
> 
> > 	http://osb.sra.co.jp/PowerGres/
> 
> Is there an English translation of the site so one who doesn't speak or write 
> Japanese can try it out?

No, sorry.  Tatsuo mentioned that.  However, Babelfish will do the
translation:

	http://world.altavista.com/

Put in the URL, and choose translate Japanese to English.

-- 
  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

Re: Windows Build System - My final thoughts

Bruce Momjian <pgman@candle.pha.pa.us> — 2003-02-02T12:19:24Z

Jeff Davis wrote:
> > 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.
> 
> I'm ignorant when it comes to build environments on windows, but I was under 
> the impression that DJGPP was mostly a complete environment. Are there any 
> plans to support it, or is it even possible?

I don't think we want to throw our Unix folks into culture shock.  Let's
pick one build environment and go from there, either cygwin or something
else.  Once the patches are in, folks can test the various build options.

-- 
  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

Re: Windows Build System - My final thoughts

Bruce Momjian <pgman@candle.pha.pa.us> — 2003-02-02T12:21:58Z

Justin Clift wrote:
>   + Aside from all this, it might be nice to have a few Win32 specific 
> gui pieces in place at the time that PostgreSQL 7.4 Win32 is released. 
> Am sure they'll develop over time, but was thinking we should at least 
> make a good impression with the first release.  Hey, if we make a really 
> bad impression with the first release, then there might not be the 
> quadruple-zillion Windows PG users after all.  If that sounds like a 
> good idea, maybe adding the GUC variables "random_query_delay" 
> (minutes), "crash_how_often" (seconds), and "reboot_plus_corrupt_please" 
> (true/false)?

What we need is for the backend to query postgresql.org to set those
parameters, so we can control how many Win32 users adopt PostgreSQL.  :-)

-- 
  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

Re: Windows Build System - My final thoughts

Justin Clift <justin@postgresql.org> — 2003-02-02T15:01:26Z

Bruce Momjian wrote:
> Justin Clift wrote:
> 
>>  + Aside from all this, it might be nice to have a few Win32 specific 
>>gui pieces in place at the time that PostgreSQL 7.4 Win32 is released. 
>>Am sure they'll develop over time, but was thinking we should at least 
>>make a good impression with the first release.  Hey, if we make a really 
>>bad impression with the first release, then there might not be the 
>>quadruple-zillion Windows PG users after all.  If that sounds like a 
>>good idea, maybe adding the GUC variables "random_query_delay" 
>>(minutes), "crash_how_often" (seconds), and "reboot_plus_corrupt_please" 
>>(true/false)?
> 
> 
> What we need is for the backend to query postgresql.org to set those
> parameters, so we can control how many Win32 users adopt PostgreSQL.  :-)

"All your [data] base belong to us" ?

;-)

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

Re: [mail] Re: Windows Build System

Igor Georgiev <gory@alphasoft-bg.com> — 2003-02-03T11:29:27Z

----- Original Message -----
From: "Justin Clift" <justin@postgresql.org>
To: "Curt Sampson" <cjs@cynic.net>
Cc: "Peter Eisentraut" <peter_e@gmx.net>; "Curtis Faith"
<curtis@galtcapital.com>; <pgsql-hackers@postgresql.org>
Sent: Sunday, February 02, 2003 4:42 AM
Subject: Re: [mail] Re: [HACKERS] Windows Build System
>   + It would be greatly helpful to have some way for the install program
> to automatically add the "Log in as a service" Win32 priviledge to the
> "postgres" user without having to instruct the user to do so.  We can
> create the user automatically through a shell command, but no idea how
> to add that permission.  If someone could do some Win32 API stuff to do
> it behind the scenes without a shell command even, that would be great.
>
>   + The WinMaster project is a first go at creating a Win32 GUI command
> console for controlling the PostgreSQL service.  It's still a bit too
> basic for real use though:
>     http://gborg.postgresql.org/project/winmaster/projdisplay.php>
> Further suggestions, volunteers, etc are totally welcome.
> :-)
> Regards and best wishes,
> Justin Clift

 It's still a bit too  basic for real use though:
Yeah i know. I write this for my internal use.
Initial purpose of this stuff is only to avoid teaching of an old lady with
minimum computer skills to use bash and hide this ugly dos box :)
Mark L. Woodward (mlw) anounce few monts ago a self installing PostgreSQL
for Windows so
i write him about this console. He do a lof job to.
Special thanks Mark.

OK, now how to make WinMaster more usefull ?
It's open source so if any1 want use it he/she may help to
develop it.

I.     Install as a service feature for winmaster are included in my plans
for future.
II.    I'm thinking about direct link to PostgreSQL server instead usung
CreateProcess,
        but this is unclear idea at present time. Any suggestions will be
welcome.
III    Please add any feature rquests to
http://gborg.postgresql.org/project/winmaster/bugs/buglist.php?fr=yes
        and ideas to mailto:winmaster-general@gborg.postgresql.org

Justin you are right !!!
Further suggestions, volunteers, etc are totally welcome!!!
    Further suggestions, volunteers, etc are totally welcome!!!
        Further suggestions, volunteers, etc are totally welcome!!!



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/01/2003

Re: [mail] Re: Windows Build System

Jan Wieck <janwieck@yahoo.com> — 2003-02-03T21:20:09Z

Hannu Krosing wrote:
> 
> On Thu, 2003-01-30 at 20:29, Tom Lane wrote:
> > 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 ?

The testing has to be done before we make anything available as an
official release. As of now, the status of this project is at the
beginning of incorporating a 7.2.1 based patch into CVS HEAD.

Asking for exzessive tests at this stage of development and (ab)using
the absence of 100% proof of rock solid reliability as an excuse to
reject the entire aproach would be ridiculous.

Jan

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

Re: Windows Build System - My final thoughts

Jan Wieck <janwieck@yahoo.com> — 2003-02-03T21:59:53Z

Lamar Owen wrote:
> 
> On Friday 31 January 2003 03:21, Bruce Momjian wrote:
> > Man, I go away for one day, and look what you guys get into.  :-)
> 
> No duh.  Whew.
> 
> > Lastly, SRA just released _today_ their first Win32 port of PostgreSQL,
> > and it is _threaded_:
> 
> >       http://osb.sra.co.jp/PowerGres/
> 
> Is there an English translation of the site so one who doesn't speak or write
> Japanese can try it out?

Bruce, better be careful!

If SRA hasn't done exzessive power-off and other crash testing, beware
of the dogs :-)


Jan

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