On Fri, 2016-03-11 at 16:40 -0800, Peter Geoghegan wrote: > 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.
Right, but isn't there a difference between the two functions in this respect? Once you find corruption involving relationship between multiple pages, then I agree it's complicated to do any reasoning about what additional checks are safe. But does that problem also apply to bt_index_check, which checks pages independently? Admittedly, this also depends on the use case. If all we need to do is answering a question "Is the index corrupted?" then sure, bailing out on the first error is perfectly appropriate. But perhaps this would be useful for some recovery/forensics tasks? >From time to time we need to investigate corruption in a database, i.e. see how much of the data is actually corrupted, list pages that need to be zeroed to get the cluster up to salvage as much as possible, etc. Currently this is tedious because we essentially find/fix the pages one by one. It'd be very useful to list all broken pages in one go and then fix all of them. Obviously, that's about heapam checks, but perhaps it would be useful for an index too? regard -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers