Re: beta testing version

On Fri, Dec 01, 2000 at 01:54:23AM -0500, Alex Pilosov wrote:
> On Thu, 30 Nov 2000, Nathan Myers wrote:
> > After a power outage on an active database, you may have corruption
> > at low levels of the system, and unless you have enormous redundancy
> > (and actually use it to verify everything) the corruption may go
> > undetected and result in (subtly) wrong answers at any future time.
>
> Nathan, why are you so hostile against postgres? Is there an ax to grind?

Alex, please don't invent enemies. It's clear what important features
PostgreSQL still lacks; over the next several releases these features
will be implemented, at great expense. PostgreSQL is useful and usable
now, given reasonable precautions and expectations. In the future it
will satisfy greater (albeit still reasonable) expectations.

> The conditions under which WAL will completely recover your database:
>
> 1) OS guarantees complete ordering of fsync()'d writes. (i.e. having two
> blocks A and B, A is fsync'd before B, it could NOT happen that B is on
> disk but A is not).
> 2) on boot recovery, OS must not corrupt anything that was fsync'd.
>
> Rule 1) is met by all unixish OSes in existance. Rule 2 is met by some
> filesystems, such as reiserfs, tux2, and softupdates.

No. The OS asks the disk to write blocks in a certain order, but
disks normally reorder writes. Not only that; as noted earlier,
typical disks report the write completed long before the blocks
actually hit the disk.

A logging file system protects against the simpler forms of OS crash,
where the OS data-structure corruption is noticed before any more disk
writes are scheduled. It can't (by itself) protect against disk
errors. For critical applications, you must supply that protection
yourself, with (e.g.) battery-backed mirroring.

> > The logging in 7.1 protects transactions against many sources of
> > database crash, but not necessarily against OS crash, and certainly
> > not against power failure. (You might get lucky, or you might just
> > think you were lucky.) This is the same as for most databases; an
> > embedded database that talks directly to the hardware might be able
> > to do better.

The best possible database code can't overcome a broken OS or a broken
disk. It would be unreasonable to expect otherwise.

Nathan Myers
ncm(at)zembu(dot)com