Re: Simplifying wal_sync_method

On Tue, Aug 09, 2005 at 12:25:36PM +0300, Marko Kreen wrote:
> On Tue, Aug 09, 2005 at 10:08:25AM +0200, Magnus Hagander wrote:
> > Most filesystem corruptions that happen on windows are because people
> > enable write caching on drives without battery backup. The same issue
> > we're facing here, it's *not* a problem in the fs, it's a problem in the
> > admin. Sure, there are lots of things that could be better with ntfs,
> > but I would definitly not call it unreliable.
> People enable?  Isn't it the default?

I think a little too much speculation in this thread, and not enough real
data... :-)

I only have Windows notebooks, and pre-configured systems by the company
I work for to judge. The notebooks of course have it 'on' (battery packed,
and if it wasn't on, I would have enabled it myself). I won't bother to
check the corporate systems, as whatever they are, they may not be the
Windows system default. Who knows for real?

In any case - I disagreed with the conclusions presented that
suggested that Windows had a poor file system, or should be linked
with poor hardware. Seems like FUD to me, and doesn't match my
experiences. I agree with the other poster that Windows hardware is
usually better in actual professional server environments. It might be
because people feel Windows requires better hardware to be stable, or
it might be that Windows applications tend to use more memory and disk
space, therefore the recommended entry level system is of higher
quality. It doesn't matter why people do it - or even if their reasons
are valid - what does matter, is that it isn't a fair conclusion that
Windows boxes will use poorer hardware. The opposite may be true, or
neither may be true.

> > I don't know anybody who claims to run a professional business who uses
> > IDE drives in a Windows server, for example. I know several who run
> > linux or freebsd on it.
> The professional probably tests it on his own desktop.  I don't
> think PostgreSQL reaches the data center before passing the run
> on desktop.

I don't know why this would be relevant.  The 'professional' may do
some sort of local testing, but this doesn't negate the requirement
for server testing, as it should be well known that the environment is
sufficiently different, and therefore the expectations should be
sufficiently different. The 'professional' may choose to enable write
caching, because they don't care about reliability on their local
system. If it crashes, they re-clone their system, and re-populate the
database. In any case, this is more speculation, and not productive.

> > > Options:
> > > -  Win32 guy complains that PG is bit slow.
> > >    We tell him to RTFM.
> > What most often happens here is:
> > Win32 guy notices PG is very slow, changes to mysql or mssql.
> But lost database is no problem?

Personally, my only complaint regarding either choice is the
assumption that a 'WIN32' guy is stupid, and that 'WIN32' itself is
deficient. As long as the default is well documented, I don't have a
problem with either 'faster but less reliable on systems configured
for speed over reliability at the operating system level (write
caching enabled)' or 'slower, but reliable, just in case the system is
configured for speed over reliability at the operating system level
(write caching enabled)'. As long as it is well documented, either is
fine. I'm not convinced that Linux is really that much safer anyways,
and when it comes to a standard WIN32 configuration option, I assume
that the WIN32 administrator is somewhat competent.

You guys are too deep-routed in UNIX-land. I can't entirely blame you
- but the world is bigger than UNIX. :-)

Cheers,
mark

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
 One ring to rule them all, one ring to find them, one ring to bring them all                      and in the darkness
bindthem...
 
                          http://mark.mielke.cc/