On 2/28/07, Gregory Stark <stark@enterprisedb.com> wrote:
> "Jonah H. Harris" <jonah.harris@gmail.com> writes:
>
> > Which is, of course, how everyone else does it.
>
> I happen to agree with your conclusion but this line of argument is
> exceptionally unconvincing. In fact in this crowd you'll tend to turn people
> off and lose people if you say things like that rather than convince anyone of
> anything.
Rather than reinventing the wheel, it often pays to piggyback on the
solutions others in similar situations have encountered. I'm just
stating how others provide similar functionality or capabilities. If
someone dislikes an idea just because the major vendors have done it
that way, that's their own problem. It's up to the community to
decide how to proceed given the information at hand.
> > Even pages from the last checkpoint would be a killer.
>
> Hm that's an interesting thought. We only really have to check pages that
> would have received a full page write since the last checkpoint.
That's the only way I see that it could possibly be acceptable from a
time-to-recover performance standpoint. I would still prefer a guc.
> Which is pretty poor design. If we implemented a fsck-like tool I would be far
> more interested in checking things like "tuples don't overlap" or "hint bits
> are set correctly" and so on. Checksums do nothing to protect against software
> failures which is the only kind of failure with a good rationale for being in
> an external tool.
Regardless of whether it's better as a separate tool or in the
database itself, they provide a
corruption-finding/consistency-checking capability. As far as other
checks that could be performed, SQL Server and Oracle do have their
own internal structure checks; many of which execute at runtime, not
as a separate tool or process.
--
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/
