| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
| Subject: | Re: amcheck (B-Tree integrity checking tool) |
| Date: | 2016-03-12 00:40:14 |
| Message-ID: | CAM3SWZT+pcwu2ozGgfNk-APr3tpJwqvqjo0qXaDvSyvGU+Si6g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 11, 2016 at 4:17 PM, Peter Geoghegan <pg(at)heroku(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2016-03-12 00:45:48 | Re: amcheck (B-Tree integrity checking tool) |
| Previous Message | Jim Nasby | 2016-03-12 00:35:17 | Re: Is there a way around function search_path killing SQL function inlining? - and backup / restore issue |