Re: quick review - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: quick review
Date
Msg-id 1164109761.3841.304.camel@silverbirch.site
Whole thread Raw
In response to quick review  ("Molle Bestefich" <molle.bestefich@gmail.com>)
List 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




pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Custom Data Type Question
Next
From: Tatsuo Ishii
Date:
Subject: Re: [PATCHES] replication docs: split single vs.