Re: quick review

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Molle Bestefich" <molle(dot)bestefich(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: quick review
Date: 2006-11-21 11:49:20
Message-ID: 1164109761.3841.304.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2006-11-20 at 17:09 +0100, Molle Bestefich wrote:

> Looks good feature-wise, but there's a suspicious lack of reference to
> any kind of repair utility for damaged data files. Hmm. I've been
> using computers for long enough that I know that in the real world
> there's no such thing as "data corruption doesn't occur", so it's
> rather suspicious.

There *is* a repair utility for damaged data files. It is the
*automatic* crash recovery feature of the database, hence the lack of a
separate repair utility.

PostgreSQL presumes that if the system crashes that you want your
database to come up in a consistent state because your data is extremely
valuable. There isn't a mode where the database comes up but some of
your files are suspect and we make you run a utility to get things back
to normal (maybe) - that is the way of doing things that you should be
somewhat skeptical of.

There is a parameter to zero_damaged_pages which can be used in
conjunction with the VACUUM utility to recover a database that has some
very bad data in it, but that is usually a response to hardware error.

Anyway, thanks very much for explaining your viewpoint. That helps us to
understand the mindset of non-users. We'll try to improve the docs to
explain why we don't need a separate tool to recover the database.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2006-11-21 14:04:58 Re: [PATCHES] WIP 2 interpreters for plperl
Previous Message Martijn van Oosterhout 2006-11-21 10:29:45 Re: [HACKERS] Client SSL validation using root.crt