 

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

Thu, 5 Feb 2004 09:01:46 -0000
"Dave Page" <dpage@vale-housing.co.uk>
Re: PITR Dead horse? 
> > 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
Thu, 05 Feb 2004 09:12:59 -0500
Rod Taylor <rbt@rbt.ca>
Re: PITR Dead horse?
> -----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


Thu, 5 Feb 2004 19:34:55 +0200
"Nicolai Tufar" <ntufar@pisem.net>
Re: PITR Dead horse? 
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.


Mon, 9 Feb 2004 10:04:56 -0700 (MST)
"scott.marlowe" <scott.marlowe@ihs.com>
Re: PITR Dead horse?
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)

Wed, 11 Feb 2004 17:43:41 -0300
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: PITR Dead horse?

"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


14 May 2004 01:17:30 -0400
Greg Stark <gsstark@mit.edu>
Re: PITR Dead horse?