On Fri, Mar 11, 2016 at 4:17 PM, Peter Geoghegan <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
