Thread

1. Re: Simplifying wal_sync_method

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

   > > 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?
   
   I dunno about workstation OS, but on the server OSes it certainly isn't
   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.
   
   I can't speak for others, but I would always test a server product on a
   server OS on server hardware. Certainly not as beefy as eventual
   production server, but the same level. Otherwise the test is not fully
   relevant.
   
   > > > 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.
   
   AFAIK fsync is slightly safer than open_sync, because it also flushes
   the metadata. We don't default to that.
   
   > > > 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?
   > 
   
   It certainly is. That's not what I'm arguing. What I'm saying is that
   you shouldn't expect server grade reliabilty on desktop hardware and
   desktop OS. Regardless of platform.
   
   //Magnus
   
   

2. Re: Simplifying wal_sync_method

   Marko Kreen <marko@l-t.ee> — 2005-08-09T10:30:34Z

   On Tue, Aug 09, 2005 at 12:14:09PM +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?
   > 
   > I dunno about workstation OS, but on the server OSes it certainly isn't
   > default.
   
   At least on XP Pro it is default.
   
   
   > > 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 can't speak for others, but I would always test a server product on a
   > server OS on server hardware. Certainly not as beefy as eventual
   > production server, but the same level. Otherwise the test is not fully
   > relevant.
   
   You are right, but it always does not happen so.  Also think of
   developers who run a dev-server on a desktop.
   
   
   > > > > 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.
   > 
   > AFAIK fsync is slightly safer than open_sync, because it also flushes
   > the metadata. We don't default to that.
   
   At least for WAL, the metadata does not change so it should not matter.
   
   Now thinking about it, the guy had corrupt table, not WAL log.
   How is WAL->tables synched?  Does the 'wal_sync_method' affect
   it or not?
   
   Ofcourse, postgres could get corrupt data from WAL and put it
   into table.  (AFAIK NTFS does not log data, so we are back on
   wal_sync_method.)
   
   > > > > 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?
   > 
   > It certainly is. That's not what I'm arguing. What I'm saying is that
   > you shouldn't expect server grade reliabilty on desktop hardware and
   > desktop OS. Regardless of platform.
   
   But we should expect server-grade speed?  ;)
   
   -- 
   marko