Re: amcheck (B-Tree integrity checking tool) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: amcheck (B-Tree integrity checking tool)
Date
Msg-id CAM3SWZQN=_45w6zqRFgmecX9RsgicV_YsPktyh9=mAcE8DPvUA@mail.gmail.com
Whole thread Raw
In response to Re: amcheck (B-Tree integrity checking tool)  (Kevin Grittner <kgrittn@gmail.com>)
Responses Re: amcheck (B-Tree integrity checking tool)  (Peter Geoghegan <pg@heroku.com>)
Re: amcheck (B-Tree integrity checking tool)  (Michael Paquier <michael.paquier@gmail.com>)
Re: amcheck (B-Tree integrity checking tool)  (Andres Freund <andres@anarazel.de>)
Re: amcheck (B-Tree integrity checking tool)  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On Fri, Sep 2, 2016 at 11:19 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
> IMV the process is to post a patch to this list to certify that it
> is yours to contribute and free of IP encumbrances that would
> prevent us from using it.  I will wait for that post.

I attach my V3. There are only very minor code changes here, such as
breaking out a separate elevel constant for DEBUG2 traces that show
information of how the B-Tree is accessed (e.g. current level, block
number). Tiny tweaks to about 3 comments were also performed. These
changes are trivial.

I've also removed the tests added, since external sort regression test
coverage is in a much better place now.

Finally, the documentation was updated, to make it closer to the
Github project's documentation. I expanded what was started as the
original amcheck sgml documentation based on the experience of using
amcheck on production databases at Heroku. This isn't a big change,
but it's the biggest in V3. The documentation now emphasizes the
likelihood of amcheck finding software errors, which is all we found.
Jim Gray predicted that fault tolerant systems will tend to have
almost all problems arise from operator error and software faults in
practice, so perhaps I should have predicted that that would be the
general trend.

--
Peter Geoghegan

Attachment

pgsql-hackers by date:

Previous
From: Andrew Borodin
Date:
Subject: Re: GiST penalty functions [PoC]
Next
From: Marko Tiikkaja
Date:
Subject: Re: SELECT FOR UPDATE regression in 9.5