Re: quick review - Mailing list pgsql-hackers

From Neil Conway
Subject Re: quick review
Date
Msg-id 1164126232.23622.124.camel@localhost.localdomain
Whole thread Raw
In response to Re: quick review  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: quick review  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 2006-11-21 at 00:00 -0500, Tom Lane wrote:
> In my mind, the existence of an automated repair utility is an admission
> that the software it's for is insufficiently robust.  When we find a
> repeatable data corruption scenario in Postgres, we *fix the bug*, we
> don't make something to clean up after an unfixed bug.

If it's a question of priorities, I completely agree: clearly the
primary focus should be on writing reliable software that doesn't need
repair utilities, and I think by that measure we've been doing pretty
well. But I don't think the need for these kind of tools can be
discounted entirely: hardware problems frequently cause data corruption,
and the number of future Postgres data-loss bugs is likely to be
non-zero, despite our best efforts.

Having better tools is hardly a bad thing, and I don't think having
better tools would require making an "admission" about the reliability
of our software. I was just saying that there's room for improvement:
for instance, tools like pg_filedump and pgfsck could be a lot more
polished and feature-complete, and the whole process of recovering from
data corruption could be better documented. Again, I don't think it is
our top priority, but if someone wants to work on it, I wouldn't stop
them...

-Neil




pgsql-hackers by date:

Previous
From: "J. Andrew Rogers"
Date:
Subject: Re: Build a Spatial Database Cache based on PostgreSQL and PostGIS
Next
From: Tom Lane
Date:
Subject: Re: quick review