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 CAM3SWZT+pcwu2ozGgfNk-APr3tpJwqvqjo0qXaDvSyvGU+Si6g@mail.gmail.com
Whole thread Raw
In response to Re: amcheck (B-Tree integrity checking tool)  (Peter Geoghegan <pg@heroku.com>)
Responses Re: amcheck (B-Tree integrity checking tool)
List pgsql-hackers
On Fri, Mar 11, 2016 at 4:17 PM, Peter Geoghegan <pg@heroku.com> wrote:
> If you want the tool to limp on when it finds an error, that can be
> done by changing the constant for the CORRUPTION macro in amcheck.c.
> But having that be dynamically configurable is not really compatible
> with the goal of having amcheck be run routinely.

Also, it's just really hard to reason about what remains OK to check
after the first problem is encountered in the general case. It's
"unreasonable" for any of the checks to ever fail. So, by that
standard, assuming that they might fail at all could be called
paranoid. Who can say what "paranoid enough" should be? I think it's
useful to have a low-impact, generic check function for B-Tree
indexes, but I don't think we need to hold back on being exhaustive
elsewhere.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Is there a way around function search_path killing SQL function inlining? - and backup / restore issue
Next
From: Peter Geoghegan
Date:
Subject: Re: amcheck (B-Tree integrity checking tool)