On 2/28/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
"Jonah H. Harris" <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED]
Iselin, New Jersey 08830 | http://www.enterprisedb.com/
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
