From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Molle Bestefich <molle(dot)bestefich(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: quick review |
Date: | 2006-11-21 16:23:52 |
Message-ID: | 1164126232.23622.124.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-11-21 16:36:01 | Re: quick review |
Previous Message | David Fetter | 2006-11-21 16:09:18 | Re: Open source databases '60 per cent cheaper' |