Thread

1. Re: Simplifying wal_sync_method

   Magnus Hagander <mha@sollentuna.net> — 2005-08-09T08:08:25Z

   > > > I think we should offer the reliable option by default, 
   > and mention 
   > > > the fast option for those who have battery-backed cache 
   > in the manual.
   > > 
   > > But only on Win32?
   > 
   > We should do what's possible with what's given to us.
   > 
   > On Win32:
   > 
   > 1.  We can write through cache.
   
   Yes.
   
   > 2.  We have unreliable OS with unreliable filesystem.
   
   That can definitly be debated. Properly maintaned on proper hardware,
   it's quite reliable these days.
   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.
   
   
   > 3.  The probability of mediocre hardware is higher.
   
   I would say it's actually *lower*. If you look in the average
   datacenter, I bet you'll find a lot more linux boxes running on
   built-at-home-with-the-cheapest-parts boxes. Whereas your windows boxes
   will run on HP or IBM or whatever real server-grade hardware.
   
   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.
   
   
   > Regular POSIX:
   > 1.  We can't write through cache.
   > 2.  We have good OS with good filesystem (probably even
   >     journaled).
   
   NTFS is journaled, BTW. And I've seen a lot more corruption on ext2,
   extr3 or reiser than I'ev seen on NTFS in my datacenter - and I have
   about 5 times more Windows server than linux...
   Granted other unixen might be more stable, I don't run any of those..
   
   
   > 3.  The probably of mediocre hardware is lower.
   
   See above.
   
   
   > Why shouldn't we offer reliable option to win32?
   
   *we do offer a reliabel option*.
   Same as on POSIX, we don't enable it by default for *non-server
   hardware*.
   
   
   > 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.
   
   
   > PS.  Yeah, I was the guy who helped him to restore what's left.
   > I'd say he wasn't exactly happy.
   
   I bet. Has he looked over all his other windows servers that are
   improperly configured with regards to write cache?
   
   //Magnus
   
   

2. Re: Simplifying wal_sync_method

   Marko Kreen <marko@l-t.ee> — 2005-08-09T09:25:36Z

   On Tue, Aug 09, 2005 at 10:08:25AM +0200, Magnus Hagander wrote:
   > That can definitly be debated. Properly maintaned on proper hardware,
   > it's quite reliable these days.
   > 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?
   
   > > 3.  The probability of mediocre hardware is higher.
   > 
   > I would say it's actually *lower*. If you look in the average
   > datacenter, I bet you'll find a lot more linux boxes running on
   > built-at-home-with-the-cheapest-parts boxes. Whereas your windows boxes
   > will run on HP or IBM or whatever real server-grade hardware.
   > 
   > 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.
   
   > > Regular POSIX:
   > > 1.  We can't write through cache.
   > > 2.  We have good OS with good filesystem (probably even
   > >     journaled).
   > 
   > NTFS is journaled, BTW. And I've seen a lot more corruption on ext2,
   > extr3 or reiser than I'ev seen on NTFS in my datacenter - and I have
   > about 5 times more Windows server than linux...
   > Granted other unixen might be more stable, I don't run any of those..
   > 
   > > 3.  The probably of mediocre hardware is lower.
   > 
   > See above.
   
   Ok, comparing impressions is not productive.
   
   
   > > Why shouldn't we offer reliable option to win32?
   > 
   > *we do offer a reliabel option*.
   > Same as on POSIX, we don't enable it by default for *non-server
   > hardware*.
   
   What do you mean here?  AFAIK we try to be reliable on POSIX too.
   
   
   > > 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?
   
   -- 
   marko
   
   
   

3. Re: Simplifying wal_sync_method

   Mark Mielke <mark@mark.mielke.cc> — 2005-08-09T14:22:31Z

   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 bind them...
   
                              http://mark.mielke.cc/
   
   
   

4. Re: Simplifying wal_sync_method

   Adrian Maier <adrian.maier@gmail.com> — 2005-08-10T06:50:28Z

   On 8/9/05, mark@mark.mielke.cc <mark@mark.mielke.cc> wrote:
   > 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.
   
   Hello guys,
   
   There seem to be arguments for both possible default configurations
   "faster but less reliable" and "slower but reliable". I personally think
   that the safer configuration is better.
   
   Anyway, i have an idea : 
   
   What do you think about letting the person who installs PostgreSQL
   on Win32 decide?  For Windows, we have the graphical installer 
   that can be improved so that the user is asked to choose between 
   the two possible configurations.  
   
   This way the user will be aware of this choice even if he/she does not 
   read the docs. 
   
   If we let this choice be made at installation time, it would be less 
   important which is the default value because i think that the users
   who install PostgreSQL from sources on Win32 are fewer. 
   And we can expect that, after bothering to install mingw and compile
   PostgreSQL,   they will also bother to configure it according to 
   their needs.  
   
   
   Cheers,
   Adrian Maier