On Fri, Mar 11, 2016 at 6:33 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > 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?
I think so, yes. > 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? Maybe, but I feel like making it possible to change the CORRUPTION elevel macro was the right trade-off. I don't want to have to reason about the universe of possible problems that could occur when the tool must limp on in the event of corruption. For example, I don't want to have to deal with infinite loops. In practice, an expert would probably be fine to change the constant themselves if they needed to. Indexes can always be rebuilt. The tool is for identifying and diagnosing corruption, but if you want to diagnose a faulty opclass or something, then I think you need to get out pageinspect. You need human judgement for that. > 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? Only insofar as it helps diagnose the underlying issue, when it is a more subtle issue. Actually fixing the index is almost certainly a REINDEX. Once you're into the messy business of diagnosing a problematic opclass, you have to be an expert, and tweaking amcheck for your requirements (i.e. rebuilding from source) becomes reasonable. Part of the reason that the code is so heavily commented is to make it hackable, because I do not feel optimistic that I can get an expert-orientated interface right, but I still want to make the tool as useful as possible to experts. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers