Thread

1. Re: PITR Dead horse?

   Dave Page <dpage@vale-housing.co.uk> — 2004-02-05T09:01:46Z

    
   
   > -----Original Message-----
   > From: Nicolai Tufar [mailto:ntufar@pisem.net] 
   > Sent: 05 February 2004 08:15
   > To: Dave Page
   > Subject: RE: [HACKERS] PITR Dead horse? 
   > 
   > > -----Original Message-----
   > > From: Dave Page [mailto:dpage@vale-housing.co.uk] Well I've 
   > only been 
   > > using PostgreSQL since 1997 and the *only* release
   > I
   > > ever had problems with was 6.3.2. We also use(d) Informix SE, DB2, 
   > > Unidata and SQL Server and only Informix and Unidata come 
   > close to the 
   > > robustness of PostgreSQL - and they're not the ones we need 
   > to worry 
   > > about.
   > 
   > Don't know. But apparently different users will have 
   > different demands From a database.
   
   Of course, but I would argue that my claim that PostgreSQL is reliable
   is backed up by the lack of people posting messages like 'we had a
   powercut and now my DB is hosed'.
   
   > > Now I'm not saying we shouldn't be continually looking to improve 
   > > things, but I don't think this is quite the problem you imply.
   > 
   > For the customers I am dealing with it is quite a problem, believe me.
   
   Do they have specific problems with the reliability of PostgreSQL then?
   Perhaps you could post details of how things have gone wrong for them
   (assuming you haven't already - I don't recall anything on -hackers
   recently).
   
   Regards, Dave
   
   

2. Re: PITR Dead horse?

   Rod Taylor <rbt@rbt.ca> — 2004-02-05T14:12:59Z

   > > Don't know. But apparently different users will have 
   > > different demands From a database.
   > 
   > Of course, but I would argue that my claim that PostgreSQL is reliable
   > is backed up by the lack of people posting messages like 'we had a
   > powercut and now my DB is hosed'.
   
   One thing we could use (and I have no idea how to do it) is a "This
   hardware is not appropriate for a database" test kit.
   
   Something to detect lying disks, battery backed write cache that isn't
   so battery backed, etc.
   
   -- 
   Rod Taylor <rbt [at] rbt [dot] ca>
   
   Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
   PGP Key: http://www.rbt.ca/rbtpub.asc
   

3. Re: PITR Dead horse?

   ntufar <ntufar@pisem.net> — 2004-02-05T17:34:55Z

   > -----Original Message-----
   > From: Dave Page [mailto:dpage@vale-housing.co.uk]
   > Sent: Thursday, February 05, 2004 11:02 AM
   > To: ntufar@pisem.net; pgsql-hackers@postgresql.org
   > Subject: RE: [HACKERS] PITR Dead horse?
   > Of course, but I would argue that my claim that PostgreSQL is reliable
   > is backed up by the lack of people posting messages like 'we had a
   > powercut and now my DB is hosed'.
   
   It's not like that. It's more like 'what will happen if we had a
   powercut/
   disk failure/cpu failure/memory failure, etc, etc.' and that answer I
   have
   to give is 'why, there is PITR of course!'. No other answer will pass in
   enterprise world. Those people are not open-minded, they'd rather be
   safe
   than sorry.
   
   > 
   > Do they have specific problems with the reliability of PostgreSQL
   then?
   > Perhaps you could post details of how things have gone wrong for them
   > (assuming you haven't already - I don't recall anything on -hackers
   > recently).
   
   Nothing remarkable. PostgreSQL just works. Bu as I said before,
   In enterprise world, good sleep at night is treasured above all.
   
   > Regards, Dave
   
   
   

4. Re: PITR Dead horse?

   scott.marlowe <scott.marlowe@ihs.com> — 2004-02-09T17:04:56Z

   On Thu, 5 Feb 2004, Rod Taylor wrote:
   
   > > > Don't know. But apparently different users will have 
   > > > different demands From a database.
   > > 
   > > Of course, but I would argue that my claim that PostgreSQL is reliable
   > > is backed up by the lack of people posting messages like 'we had a
   > > powercut and now my DB is hosed'.
   > 
   > One thing we could use (and I have no idea how to do it) is a "This
   > hardware is not appropriate for a database" test kit.
   > 
   > Something to detect lying disks, battery backed write cache that isn't
   > so battery backed, etc.
   
   but I'm not sure you can test that without power off tests...  so, it 
   would have to be a test that kinda started up then told you to pull the 
   plug on the box.  Even a kernel panic wouldn't detect it because the drive 
   would still be powered up.
   
   Or, you could have a test that checked what kind of drive it was (IDE 
   versus SCSI) and maybe had a table of drives that are known to lie, 
   possibly even by version, should drives of the same model stop lying half 
   way through production due to fixes in their firmware.
   
   I'd guess it the table would still have to be built the old fashioned way, 
   by doing power off tests.
   
   
   

5. Re: PITR Dead horse?

   Alvaro Herrera <alvherre@dcc.uchile.cl> — 2004-02-11T20:43:41Z

   On Mon, Feb 09, 2004 at 10:04:56AM -0700, scott.marlowe wrote:
   > On Thu, 5 Feb 2004, Rod Taylor wrote:
   
   > > One thing we could use (and I have no idea how to do it) is a "This
   > > hardware is not appropriate for a database" test kit.
   > > 
   > > Something to detect lying disks, battery backed write cache that isn't
   > > so battery backed, etc.
   > 
   > but I'm not sure you can test that without power off tests...  so, it 
   > would have to be a test that kinda started up then told you to pull the 
   > plug on the box.  Even a kernel panic wouldn't detect it because the drive 
   > would still be powered up.
   
   Try UMLSIM, umlsim.sourceforge.net
   
   -- 
   Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
   "El destino baraja y nosotros jugamos" (A. Schopenhauer)
   
   

6. Re: PITR Dead horse?

   Greg Stark <gsstark@mit.edu> — 2004-05-14T05:17:30Z

   "scott.marlowe" <scott.marlowe@ihs.com> writes:
   
   > but I'm not sure you can test that without power off tests...  
   
   Well the approach that's been taken manually on the list is to look at the
   timing results and conclude they're just physically impossible.
   
   Doing this automatically could be interesting. If the tool were given a
   partition to act on directly it would be able to intentionally write to blocks
   in reverse order doing an fsync between each block and testing whether the
   bandwidth is low enough to conclude a full rotation between each write had
   been completed.
   
   Doing the same on the filesystem would be less reliable but might also be an
   interesting test since the OS might make fsync lie directly, or might have
   some additional intelligence in the filesystem that forces the drive to sync
   to the platters before fsync returns.
   
   -- 
   greg