Skip site navigation (1) Skip section navigation (2)

Re: beta testing version

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: beta testing version
Date: 2000-12-04 06:32:47
Message-ID: 3.0.1.32.20001203223247.01ae67c0@mail.pacifier.com (view raw or flat)
Thread:
Lists: pgsql-hackers
At 02:47 PM 12/1/00 -0500, Tom Lane wrote:

>All we can do is the best we can ;-).  In that light, I think it's
>reasonable for Postgres to proceed on the assumption that fsync does
>what it claims to do, ie, all blocks are written when it returns.
>We can't realistically expect to persuade a disk controller that
>reorders writes to stop doing so.  We can, however, expect that we've
>minimized the probability of failures induced by anything other than
>disk hardware failure or power failure.

Right.  This is very much the guarantee that RAID (non-zero) makes, 
except "other than disk hardware failure" is replaced by "other than
the failure of two drives".  RAID gives you that (very, very substantial
boost which is why it is so popular for DB servers).  It doesn't give
you power failure assurance for much the same reason that PG (or Oracle,
etc) can.

If transaction processing alone could give you protection against a 
single disk hardware failure, Oracle wouldn't've bothered implementing
mirroring in the past before software (and even reasonable hardware)
RAID was available.

Likewise, if mirroring + transaction processing could protect against
disks hosing themselves in power failure situations Oracle wouldn't 
suggest that enterprise level customers invest in external disk
subsystems with battery backup sufficient to guarantee everything
the db server believes has been written really is written.

Of course, Oracle license fees are high enough that proper hardware
support tends to look cheap in comparison...

Vadim's WAL code is excellent, and the fact that we run in essence
with -F performance and also less write activity to the disk both
increases performance, and tends to lessen the probability that the
disk will actually be writing a block when the power goes off.  The
dice aren't quite so loaded against the server with this lowered
disk activity...



- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

In response to

pgsql-hackers by date

Next:From: Thomas LockhartDate: 2000-12-04 06:42:58
Subject: Re: Using Threads?
Previous:From: Thomas LockhartDate: 2000-12-04 06:26:10
Subject: Re: postgres docs (was Re: Crash during WAL recovery?)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group